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PREFACE 


Introduction  Training  developers  responsible  for  the  acquisition  of  training  devices  to 

support  training  on  new  systems  or  training  programs  are  unique  within 
the  U.S.  Army  Training  and  Doctrine  Command  (TRADOC)  training 
community.  In  addition  to  performing  the  normal  training  development 
functions  of  identifying  training  deficiencies,  analyzing  training 
requirements,  and  determining  appropriate  solutions  to  the  deficiencies, 
these  training  developers  must  also  perform  duties  of  the  combat 
developer  in  developing  materiel  requirement  documentation  and 
interacting  with  the  U.S.  Army  Materiel  Command  (AMC)  in  the  materiel 
acquisition  process. 


Purpose  This  document  is  intended  to  serve  two  purposes: 

•  As  a  vehicle  for  introducing  new  personnel  to  the  duties  of 
training  device  development  and  the  procedures  followed  within 
TRADOC. 

•  As  a  desktop  how-to  guide  for  frequently  performed  system  and 
nonsystem  training  device  development  procedures. 
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Avail  and  /  or 


The  procedures  in  this  handbook  apply  to  Headquarters  (HQ)  TRADOC 
staff  elements,  TRADOC  centers  and  schools,  and  TRADOC  agencies 
associated  with  the  training  device  acquisition  process. 

The  procedures  described  in  this  handbook  apply  to- 

•  Nonsystem  training  devices  (NSTDs)  developed  in  support  of 
general  military  training. 

•  System  training  devices  (STDs)  developed  in  support  of  new  or 
system-fielded  materiel. 
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This  handbook  was  developed  using  the  most  recent  U.S.  Army, 
TRADOC,  and  AMC  regulations  and  pamphlets  pertaining  to  training 
developments  and  to  the  materiel  acquisition  process.  Pertinent 
regulations  are  identified  throughout  the  document  to  provide  the  training 
device  developer  with  references  to  obtain  additional  information  if 
desired. 


This  handbook  has  been  developed  using  a  technique  called  information 
mapping,  a  proven  method  for  comprehensive  development  and 
presentation  of  technical  information.  Information  mapping  presents 
information  in  a  manner  that  makes  learning  and  referencing  the 
materials  both  fast  and  simple.  The  following  are  its  main  features: 

•  Information  presented  in  information  blocks. 

•  Information  labeled  by  block. 

•  Consistency  of  format  for  each  kind  of  information. 

•  A  cross-referencing  index  on  each  information  map,  providing 
quick  location  of  prerequisite  and  follow-on  information. 

Within  this  handbook,  information  is  presented  in  a  logical,  concise 
manner  using  a  collection  of  information  maps. 


An  information  block  is  the  smallest  part  of  an  information  map.  It 
consists  of  one  or  more  sentences  and/or  diagrams  about  a  fragment  of 
subject  matter  and  a  label  that  describes  the  functions  or  contents  of  the 
block.  Blocks  are  easy  to  identify  because  they  are  separated  by 
horizontal  lines  and  have  their  labels  displayed  prominently  in  the 
margin. 


An  information  map  is  a  collection  of  all  relevant  information  blocks 
about  a  given  subject.  Most  information  maps  in  this  handbook  have,  as 
the  last  information  block,  a  cross-reference  to  other  information  maps 
containing  related  material. 
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Supersession 


This  handbook  supersedes  the  Training  Developers’  Procedural  Guide 
for  Nonsystem  Training  Device  Requirements  Documentation,  dated  July 
1989,  and  the  Training  Developers'  Procedural  Guide  for  System 
Training  Device  Requirements  Documentation,  dated  September  1989. 


Feedback  The  Devices  Management  Directorate  (DMD)  at  the  'J.S.  Army  Training 

Support  Center  is  the  proponent  for  this  publication.  Users  are 
encouraged  to  provide  comments  and  suggestions  for  improvement  on 
DA  Form  2028  to- 
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CHAPTER  1 


TRAINING  DEVICE  REQUIREMENTS 


Training  Devica  Requirements 

Overview 


Introduction 


Rapidly  evolving  technology,  changing  AirLand  Battle  operations 
doctrine,  reductions  in  force,  and  budgetary  constraints  constantly 
challenge  the  U.S.  military's  ability  to  train,  deploy,  and  win. 

The  effective  employment  of  these  technologies  is  the  key  to  combat 
success  and  is  changing  the  way  the  U.S.  Army  plans  and  trains  its 
AirLand  Battle  doctrine.  The  evolution  of  technology  involves 
significantly  higher  costs  and  risks.  It  is  readily  apparent  that  the  routine 
use  of  actual  weapon  systems,  aircraft,  medical  equipment,  or  other 
system  hardware  is  not,  in  many  cases,  the  most  cost-effective  or  safest 
approach  for  initial  or  skill  retention  training. 

Training  subsystems  in  the  form  of  training  aids,  devices,  simulations, 
and  simulators  (TADSS)  are  often  the  most  effective  means  of  reducing 
the  cost  of  training  to  full  system  potential.  Training  devices  reduce 
raining  costs  and  may  also  be  the  most  effective  means  of  solving 
current  or  potential  training  deficiencies.  There  are  two  categories  of 
training  devices: 

System  training  devices  (STDs)  -  support  training  tor  a  specific  weapon 
or  equipment  system.  STDs  are  generally  developed,  documented,  and 
procured  concurrently  with  the  system. 

Nonsystem  training  devices  (NSTDs)  -  support  general  military  training. 
Training  devices  for  systems  may  in  some  instances  be  develooed  and 
procured  using  the  NSTD  process;  however,  this  does  not  relieve  the 
system  program  executive  officer  (PEO)  or  project  manager  (PM)  from 
funding  the  procurement  of  these  devices  to  support  the  system. 

It  is  the  inherent  responsibility  of  the  U.S.  Army  Training  and  Doctrine 
Command  (TRADOC)  to  identify  training  device  requirements  for 
developing  and  fielded  systems.  Training  developers  in  coordination 
with  the  combat  developers  and  materiel  developers  ensure  the  training 
subsystem  is  developed,  procured,  and  fielded  concurrently  with  the 
system. 
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Purpose 


Scope 


Training  Aids, 
Devices, 

Simulations,  and 
Simulators  (TADSS) 


The  purpose  of  this  chapter  is  to  provide  an  overview  of  the  acquisition 
process  for  STDs  and  NSTDs.  Discussions  herein  focus  generally  on 
key  elements  of  the  materiel  acquisition  process  with  specific  information 
oriented  on  the  subordinate  training  device  acquisition  process. 


This  chapter  provides  an  overview  of  the  following  areas  within  the 
training  device  acquisition  process. 

•  TADSS  Program 

•  Materiel  Acquisition 

Requirements  Generation 
Requirements  Documentation 
Funding 

Life  Cycle  Management 

Specific  and  detailed  information  on  all  major  elements  of  the  device 
acquisition  process  is  provided  in  the  ensuing  chapters  of  this  document. 
The  material  presented  herein  is  in  compliance  with  the  regulatory 
guidelines  specified  in  the  Department  of  Defense  (DOD)  Defense 
Acquisition  Management  Documentation  and  Reports  Manual  Series 
5000  and  Department  of  the  Army  (DA),  TRADOC,  and  U.S.  Army 
Materiel  Command  (AMC)  regulations  and  guidelines. 


Training  support  products  come  in  a  variety  of  configurations  ranging 
from  pocket-size  job  aids  to  full-motion  aircraft  simulators  and  embedded 
training  capabilities.  The  cost  of  production  may  range  from  several 
hundred  to  millions  of  dollars.  Because  of  the  broad  cost  range  and  the 
magnitude  of  training  products  and  subsystems,  combat,  materiel,  and 
training  developers  must  accurately  identify  and  define  the  battlefield 
mission  needs  to  ensure  that  the  U.S.  Army  gets  the  best  return,  over 
time,  on  its  training  investment. 
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TADSS  -  Types  of 
Programs 


An  example  STD  and  NSTD  are  compared  below  to  show  significant 
differences. 


SYSTEM  TRAINING  DEVICE 

Example:  Patriot  Maintenance 
Trainer 


•  Acquired  by  system  program 
executive  officer  (PEO)  or 
project  manager  (PM). 


•  Prioritized  and  funded  with 
the  system. 


•  Requirement  is  documented 
within  the  system's 
requirements  document. 

•  Procurement  may  be 
accomplished  with  the  system 
or  separately  from  the  system. 


NONSYSTEM  TRAINING  DEVICE 

Example:  Battle  Staff  Trainer 


•  Acquired  by  the 
Simulat'on,  Training,  and 
Instrumentation 
Command  (STRICOM). 

•  Prioritized  and  funded 
within  the  Training 
Mission  Area  (TMA). 

•  Requirements  are  stated 
in  device  requirements 
documents. 

•  Acquisition  is  through 
procurement  or  in-house 
development/fabrication. 


TADSS  Program 
Management 


Management  of  the  TADSS  requirements  is  the  responsibility  of  these 

activities: 

•  Assistant  Secretary  of  the  Army  for  Research,  Development,  and 
Acquisition  (ASARDA)  -  has  overall  Department  of  the  Army 
responsibility  for  research,  development,  and  acquisition 
activities. 

PEOs/PMs  •  develop  and  procure  TADSS  for  developing 
systems  under  their  purview. 

•  Headquarters,  Department  of  the  Army  (HQDA)  -  approves, 
coordinates,  and  prioritizes  TADSS  requirements,  development, 
and  acquisition. 

•  TRADOC  -  generates  and  documents  TADSS  requirements. 

U.S.  Army  Training  Support  Center  (ATSC)  -  is 
TRADOC’s  agent  for  processing  these  actions. 
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TADSS  Program 
Managemant  (con.) 


Materiel  Acquisition 


•  AMC  -  develops  and  procures  NSTDs  based  on  approved 
requirements. 

U.S.  Army  Simulation,  Training,  and  Instrumentation 
Command  (STRICOM)  -  provides  concept  formulation  for 
all  training  devices  and  development/procurement  for 
most  NSTDs. 

The  framework  for  program  management  is  the  Acquisition  Milestones 
and  Phases  model  within  the  materiel  acquisition  process. 


Materiel  acquisition  is  a  complex  procedure  comprised  of  several  unique 
processes  that  interact  on  a  routine  basis  to  ensure  requirements  are 
identified  and  documented  properly  and  the  appropriate  solutions  are 
developed  and  acquired  to  meet  the  user’s  requirements. 

The  following  are  the  primary  focuses  of  the  materiel  acquisition 
process: 

•  Requirements  generation  -  What  generates  the  requirement  for  a 
new  materiel  system  or  training  hardware? 

•  Requirements  documentation  -  How  are  these  requirements 
documented  to  provide  the  decision  makers,  engineers, 
procurement  specialists,  trainers,  and  supporting  staff  agencies  a 
clear  understanding  of  what  is  needed  and  why? 

•  Funding  -  How  are  the  necessary  funds  obtained  to  conduct 
comprehensive  research  and  to  develop  and  procure  the 
appropriate  materiel  solution? 

•  Life  cycle  management  -  How  are  the  development  and  testing  of 
emerging  materiel  tracked  to  ensure  that  what  is  being  procured 
does,  in  fact,  meet  the  user's  requirements? 

This  chapter  provides  a  broad  overview  of  how  these  areas  are 
addressed  in  the  materiel  acquisition  process.  The  succeeding  chapters 
provide  the  detail  necessary  to  support  this  process  within  DOD  and  DA 
guidelines. 
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Principles  of  Device 
Acquisition 


These  are  two  constant  principles  of  device  acquisition: 


Acquisition  Players 


TADSS  are  materiel  systems.  As  such,  their  acquisition  is 
governed  by  public  law,  DOD  directives  (5000  series),  and  U.S. 
Army  Regulations. 

The  following  are  required  in  the  procurement  of  any  device: 
Approved  materiel  requirements  document. 

Appropriate  funding. 

Acquisition  in-process  review  (I  PR)  approval  at  key 
decision  points  to  determine  if  the  initiative  should 
continue,  take  another  direction,  or  be  terminated. 


The  acquisition  of  materiel  systems  and  training  devices  for  the  U.S. 
Army  requires  close  interaction  between  several  organizations  and 
personnel.  The  major  organizations  and  agencies  are  listed  below.  In 
addition  to  these,  coordination  must  be  effected  with  other  services  and 
allied  nations  when  developing  or  procuring  new  systems  or  TADSS. 

•  DOD.  The  Under  Secretary  of  Defense  for  Research, 
Development,  and  Acquisition  is  responsible  for  managing  the 
DOD  Acquisition  Program.  The  Under  Secretary  may  appoint 
and  direct  personnel  responsible  for  study  and  acquisition  of 
materiel  at  various  levels  within  DOD. 

•  ASARDA.  The  ASARDA  exercises  responsibility  for  U.S.  Army 
materiel  acquisition  through  the  PEOs  and  PMs.  PEOs/PMs 
have  full-line  authority  to  manage  the  funding,  development,  and 
acquisition  of  a  new  system  and  associated  training  subsystems 
including  training  devices  and  embedded  training  capabilities.  A 
PEO  or  PM  is  assigned  to  each  system  under  development. 

•  HQDA.  HQDA  has  oversight  of  the  U.S.  Army’s  materiel  and 
training  device  acquisition  process.  HQDA  oversees  the 
activities  of  AMC  and  TRADOC.  Each  U.S.  Army  major 
command  (MACOM)  has  unique  functional  activities  that  directly 
interface  in  the  materiel  and  training  device  requirements 
identification  and  acquisition  arena. 


Acquisition  Players 
(con.) 


Joint  Working 
Groups  (JWGs) 


AMC.  The  AMC  works  with  the  PEO/PM  in  the  materiel 
acquisition  process.  A  subordinate  command  of  AMC  that  is  of 
vital  interest  to  the  training  developer  is  STRICOM.  STRICOM  is 
responsible  for  the  development  and  acquisition  of  NSTDs  and 
for  providing  concept  formulation  for  system  TADSS.  STRICOM 
may  also  develop  and  procure  system  TADSS  at  the  request  of 
the  system  PEO/PM. 

TRADOC.  TRADOC  develops  requirements  for  new  systems 
and  TADSS  and  is  the  users'  representative  during  the  materiel 
acquisition  process.  Key  to  the  TRADOC  effort  are  the  following: 

The  proponent  combat  developer  -  is  responsible  for 
identifying  and  defining  materiel  requirements  and 
interfacing  with  the  system  PEO/PM. 

The  proponent  training  developer  -  is  responsible  for 
identifying  training  deficiencies  and  developing  training 
programs  and  subsystems  to  correct  those  deficiencies. 
The  training  developer  interfaces  with  the  system 
PEO/PM  and  STRICOM. 

ATSC  -  has  responsibility  for  managing  the 
documentation  and  acquisition  of  training  devices  as  a 
primary  agent  for  HQDA/TRADOC.  To  this  end,  interface 
actions  routinely  include  the  combat  developer,  training 
developer,  and  materiel  developers. 


Several  types  of  JWGs  support  the  essential  interaction  process 
between  the  primary  acquisition  players.  These  JWGs  may  be 
conducted  as  combined  or  stand-alone  activities.  The  following  are 
JWGs  and  their  respective  chairpersons: 

•  Manpower  and  personnel  integration  (MANPRINT)  JWG 

(MJWG).  The  proponent  combat  developer  chairs  the  MJWG  tor 
a  materiel  system.  The  purpose  of  the  MJWG  is  to  plan  for 
MANPRINT  activities  throughout  the  system  development  cycle. 
An  outcome  of  the  MJWG  is  the  system  MANPRINT 
management  plan  (SMMP),  which  will  be  updated  throughout 
system  development.  For  NSTDs  the  MJWG  is  conducted  as 
part  of  the  training  device  JWG  1  and  is  chaired  by  the 
proponent  training  developer. 


Joint  Working 
Groups  (JWGs) 
(con.) 


Requirements 

Generation 


•  System  mission  need  statement  (MNS)  JWG.  The  proponent 
combat  developer  chairs  the  MNS  JWG  for  a  materiel  system. 
The  MNS  JWG  is  convened  to  obtain  input  from  major  players  in 
the  preparation  of  the  MNS. 

•  System  operational  requirements  document  (ORD)  JWG.  The 
proponent  combat  developer  chairs  the  ORD  JWG  for  a  system. 
The  ORD  JWG  it  is  held  after  staffing  of  the  draft  ORD  with  the 
purpose  of  finalizing  the  ORD  for  submission  to  the  TRADOC 
Requirements  Review  Committee  (RRC). 

•  Training  device  JWG.  The  proponent  training  developer  chairs 
training  device  JWGs  with  the  materiel  developer  as  the  vice 
chairperson.  Normally  at  least  two  JWGs  are  conducted  for 
TADSS.  The  first,  in  general  terms,  is  to  initiate  concept 
formulation,  and  the  second  is  to  finalize  requirements 
documentation. 

•  Test  integration  working  group  (TIWG).  The  materiel  developer 
chairs  the  TIWG  for  materiel  systems  and  for  TADSS.  Several 
TIWGs  may  be  convened  throughout  system  or  TADSS 
development  as  required  to  prepare  and  update  the  test  and 
evaluation  master  plan  (TEMP)  and  to  monitor  developmental 
and  operational  testing  of  the  system  and  the  system  TADSS. 

•  Training  support  work  group  (TSWG).  The  materiel  developer 
chairs  the  TSWG.  The  purpose  is  to  coordinate  or  resolve 
issues  involving  new  equipment  training  plans  (NETPs)  for 
developing  systems  or  NSTDs. 


Requirements  for  system  and  nonsystem  TADSS  in  support  of  the 
combined  arms  training  strategy  (CATS)  are  identified  through  a 
continuous  process  of  threat-based  analysis  and  evaluation  of  the  U.S. 
Army's  capabilities  to  respond  to  existing  and  emerging  battle  concepts 
and  scenarios.  The  basis  of  this  process  consists  of  the  capability/ 
deficiency  criteria  and  the  systems  approach  to  training  (SAT). 

•  The  capability/deficiency  criteria  is  used  for  comprehensive 

analysis,  evaluation,  and  development  of  recommended  solutions 
to  existing  and/or  emerging  issues.  The  focus  is  on  the  following 
domains: 

Doctrine. 

Training. 
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Requirements  Leader  development. 

Generation  (con.) 

Organization. 

Materiel. 

Soldier. 

Training  devices  and  simulators  that  result  as  recommended  solutions  to 
capability  issues  may  fall  Into  both  the  training  domain  and  the  materiel 
domains.  However,  since  they  are  designated  as  materiel  systems, 
procurement  is  through  the  materiel  acquisition  process  except  in 
special  cases. 

The  requirements  generation  process  (as  shown  in  the  next  figure)  is  a 
recurring  and  overlapping  process.  As  such  it  is  affected  by  and 
inherently  impacts  on  other  programs  that  support  the  materiel 
acquisition  process.  These  include  the  SAT  process,  the  planning, 
programming,  budgeting,  and  execution  system  (PPBES),  and 
documentation  of  basis  of  issue  plan  and  qualitative  and  quantitative 
personnel  requirements  Information  (BOIP/QQPRI).  Each  of  these 
areas  is  addressed  In  ensuing  information  blocks  and/or  covered  in 
detail  in  subsequent  chapters. 
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Requirements 
Generation  (con.) 


Requirements 

Documentation 


The  SAT  is  a  systematic  process  to  identify  current  and  potential 
performance  deficiencies,  both  collective  and  individual,  and 
resolve  those  deficiencies  through  the  implementation  of  a 
selected  medium  such  as  training  devices  or  a  combination  of 
media  that  may  include  a  device  application.  The  interrelated 
activities  and  elements  of  the  SAT  process  are  shown  in  the 
figure  below. 
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When  the  need  for  a  training  device  has  been  identified,  it  must  be 
documented  so  that  ail  the  players  in  the  materiel  acquisition  process 
fully  understand  the  need  and  the  ultimate  requirement.  Initially,  the 
need  will  be  explained  in  relatively  general  terms.  As  analysis 
continues,  the  general  description  will  become  increasingly  detailed  and 
will  include  constraints,  essential  characteristics,  and,  eventually, 
specifications. 

It  is  the  proponent’s  responsibility  to  document  both  the  need  and  the 
requirement  for  training  devices.  NSTDs  and  STDs  are  documented 
differently: 

•  NSTDs  are  documented  using  a  MNS  and  an  ORD. 
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Requirements 

Documentation 

(con.) 


Mission  Need 
Statement  (MNS) 


Operational 
Requirements 
Document  (ORD) 


Comment 


Funding 


STDs  do  not  require  a  separate  MNS  and  ORD  since  the  training 
subsystem  (which  includes  training  devices)  is  documented, 
funded,  developed,  and  procured  with  the  system  it  supports. 

The  need  for  the  STD  will  be  identified  in  the  system  MNS  and  in 
the  Training  Support  Requirements  (TSR)  Annex  to  the  system 
ORD. 


The  MNS  is  the  initiating  document  for  all  acquisition  actions.  A  MNS 
for  a  new  system  need  defines  the  battlefield  deficiency  in  operational 
language  to  provide  multiple  options  for  analysis  during  concept  studies. 
Likewise  a  MNS  for  an  NSTD  will  describe  the  training  deficiency  in 
terms  that  will  permit  multiple  alternatives  to  be  explored  through  a 
training  effectiveness  analysis  (TEA).  Primary  responsibility  for  the 
preparation  of  the  MNS  rests  with  the  mission  area  proponent.  The 
combat  developer  formulates  the  system  MNS  with  input  from  the 
training  developer  and  the  materiel  developer.  The  training  developer 
initiates  the  NSTD  MNS,  and  it  is  supported  by  input  from  the  materiel 
deveioper. 


The  ORD,  after  approval,  allows  the  U.S.  Army  to  begin  development 
and/or  production  of  a  materiel  system  and  attendant  training  support 
systems  or  an  NSTD.  In  either  instance,  the  ORD  contains  operational 
parameters  for  the  proposed  end  item.  The  proponent  combat 
developer  prepares  the  system  ORD  with  inputs  from  the  training 
developer  and  materiel  developer.  The  NSTD  ORD  is  the  responsibility 
of  the  training  developer  with  supporting  input  from  the  materiel 
developer. 


Expanded  and  detailed  information  on  the  purposes  and  preparation  of 
the  nonsystem  and  system  MNS  and  ORD  is  contained  in  chapters  3 
and  4  respectively. 


The  overall  fiscal  management  process  that  supports  all  acquisition 
actions  is  the  DOD’s  planning,  programming,  and  budgeting  system 
(PPBS).  The  PPBS  and  its  products  provide  the  basis  for  decision 
makers  to  make  informed  affordability  assessments  and  resource 
decisions  on  defense  acquisition  programs. 
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Planning, 
Programming, 
Budgeting,  and 
Execution  System 
(PPBES) 


Programming  •  translates  goals  and  objectives  to  actions, 
considers  alternatives  and  trade-offs,  and  projects  future 
requirements  and  programs. 

Budgeting  -  in  the  broad  sense  encompasses  formulation, 
justification,  and  control  phases  of  the  budget  process. 

Execution  -  is  the  expending  of  current  fiscal  year  funds  in  the 
execution  of  the  approved  budget. 


The  DOD  PPBS  provides  funds  to  the  service  departments;  the  U.S. 
Army  uses  its  PPBES  to  execute  the  funding  of  U.S.  Army-specific 
programs.  Execution  actions  are  continually  reviewed  throughout  the 
materiel  acquisition  process.  There  are  four  key  activities: 

•  Planning  -  covers  the  definition  and  examination  of  alternative 
strategies,  analysis  of  changing  conditions  and  trends, 
assessment  of  threat  and  technology,  and  evaluation  of  long¬ 
term  implications. 


Life  Cycle  The  objective  of  life  cycle  management  is  to  track  and  guide  the 

Management  developing  item  to  ensure  that  materiel  systems  and  their  training 

subsystems  or  NSTDs  meet  user  requirements.  The  acquisition 
process,  based  on  the  DOD  Acquisition  Milestones  and  Phase  Model  as 
prescribed  in  DODI  5000.2,  Defense  Acquisition  Management  Policies 
and  Procedures,  is  depicted  below. 
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Life  Cycle 
Management  (con.) 


Milestone 

Decisions,  Levels  of 
Authority 


This  model  is  the  framework  for  managing  programs  that  fall  under  most 
acquisition  categories  (ACATs).  The  majority  of  the  U.S.  Army’s 
programs  fall  into  ACATs  III  and  IV,  and  the  management  model  is 
tailored  to  meet  program-specific  requirements.  ACATs  and  milestone 
input/decision  authority  are  covered  in  ensuing  information  blocks.  The 
following  are  the  phases  in  the  acquisition  process: 

•  Phase  0,  Concept  Exploration  and  Definition.  The  purpose  of 
this  phase  is  to  explore  and  identify  alternative  system  concepts. 
The  focus  is  on  defining  and  evaluating  these  concepts  and 
assessing  their  relative  merits  in  preparation  for  a  decision  at 
milestone  I. 

•  Phase  I,  Demonstration  and  Validation.  This  phase  is  used  to 
verify  the  proposed  system  concept,  eliminate  problems,  and 
further  examine  and  reduce  risk  factors  identified  in  phase  0. 
Phase  I  actions  include  but  are  not  limited  to  prototype 
development,  testing,  and  early  operational  assessment  of  critical 
systems,  subsystems,  and  components. 

•  Phase  II,  Engineering  and  Manufacturing  Development.  The  key 
element  of  this  phase  is  the  development  of  system-specific 
performance  requirements  and  standards  to  delineate  contract 
specifications,  Configuration  control  for  the  design  and  the 
production  processes  is  also  established  at  this  point. 

•  Phase  III,  Production  and  Deployment.  Activities  in  this  phase 
monitor  system  performance  and  quality  from  production  through 
follow-on  operational  testing.  Support  plans  are  also 
implemented  during  this  phase  to  ensure  training  devices  and 
system-related  resources  are  fielded  concurrently  with  the 
system. 

•  Phase  IV,  Operations  and  Support.  This  phase  is  initiated  after 
the  system(s)  fielding  is  complete.  Emerging  quality  and  safety 
problems  are  corrected,  appropriate  modifications  are  undertaken 
to  extend  system  service  life,  and  postfielding  supportability 
reviews  are  conducted. 


At  critical  points  in  the  development  of  materiel  systems,  the  program  is 
reviewed  and  decisions  are  made  as  to  whether  to  continue,  modify,  or 
cancel  the  program.  The  appropriate  level  of  milestone  decision 
authority  makes  these  decisions. 
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Milestone 

Decisions,  Levels  of 
Authority  (con.) 


All  acquisition  programs,  with  the  exception  of  sensitive  classified 

programs,  fall  into  one  of  four  principal  categories: 

•  ACAT  I  -  consists  of  unclassified  major  programs  ranging  from 
$200  million  to  $1  billion  (1980  constant  dollars)  in  a  fiscal  year. 
The  Under  Secretary  for  Defense  Acquisition  designates  and 
approves  these  programs.  The  DOD  component  head  or 
acquisition  executive  may  be  the  delegated  approval  authority. 

•  ACAT  II  -  encompasses  major  programs  not  meeting  ACAT  I 
criteria  with  an  eventual  projected  expenditure  of  $75  to  $300 
million  (1 980  constant  dollars)  in  a  fiscal  year.  Designation  and 
approval  authority  (if  delegated)  is  the  DOD  component  head  or 
the  DOD  acquisition  executive. 

•  ACATs  III  and  IV  -  encompass  all  programs  that  do  not  meet  the 
classification  and  cost  criteria  of  ACATs  I  and  II.  These 
categories  also  have  the  distinction  of  assignment  of  approval 
authority  to  the  lowest  level  deemed  appropriate  by  the 
designating  authority.  The  designating  authority  in  both  of  these 
categories  is  the  service  acquisition  executive. 
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DOD  Acquisition 
Milestones  end 
Phases 


The  DOD  Acquisition  Milestones  and  Phases  Model  from  DODI  5000.2 
(shown  below)  is  normally  used  for  full-scale  development  (FSD) 
programs  for  a  major  system  acquisition. 

This  model  consists  of  five  phases  and  decision  points  that  identify 
required  changes  and  determine  if  the  acquisition  process  will  continue 
from  one  phase  to  another.  The  figure  below  is  a  graphic  representation 
of  the  milestones,  phases,  time  lines,  and  associated  documentation  for 
the  FSD  Acquisition  Milestones  and  Phases  Model. 
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Tailored  Model 


The  FSD  Acquisition  Milestones  and  Phases  Model  may  be  tailored  to 
reduce  the  time  it  takes  to  validate  an  identified  need  consistent  with 
reasonable  and  sound  management  practices.  Although  milestone  I  and 
milestone  II  have  been  combined,  the  same  acquisition  documents  and 
activities  developed  and  performed  in  the  FSD  model  apply.  An 
example  of  a  tailored  life  cycle  model  (LCM)  is  shown  below. 
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Non  system  Training 
Device  Life  Cycle 
Model  (NSTD  LCM) 


The  NSTD  LCM  is  a  management  model  tailored  specifically  for  use  in 
the  development  and  acquisition  of  NSTDs.  It  has  combined  phases  I 
and  II  to  set  a  single  decision  point.  The  phases  purposely  overlap  to 
allow  flexibility  in  the  process. 


*  IF  REQUIRED 


1-16 


Summary 


The  need  for  new  TADSS  is  identified  to  meet  CATS  requirements 
through  the  SAT  process.  These  requirements  will  normally  be  general 
in  nature  and  documented  in  a  MNS.  Training  developers  and  materiel 
developers  assess  alternative  means  to  satisfy  these  needs  based  on 
current  and  emerging  technologies,  risk  factors,  capabilities  of  industry, 
and  applicable  constraints. 

Initial  affordability  decisions  on  new  acquisition  programs  must  be  made 
within  the  limits  and  guidance  of  the  PPBS,  DA  planning  initiatives, 
approved  long-range  investment  plans,  and  overall  funding  constraints. 

The  preliminary  broad  mission  statements  must  be  progressively 
translated  into  performance  requirements  and  a  stable  design  package 
that  can  be  efficiently  produced. 

Cost,  performance,  and  schedule  trade-offs  must  be  made  throughout 
the  course  of  the  acquisition  program.  These  trade-offs  are  based  on 
the  status  of  program  execution,  risk  assessment,  testing  results,  and 
affordability  constraints  within  the  life  cycle  management  process. 

These  key  interactions  are  depicted  below. 
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Summary  (con.) 


The  remainder  of  this  procedural  guide  provides  the  detail  necessary  for 
TRADOC  training  developers  to  fulfill  their  responsibilities  in  the 
identification  of  STD  and  NSTD  requirements,  the  development  of 
appropriate  documentation,  and  the  execution  of  training  development 
actions  and  interactions  under  the  materiel  acquisition  process. 

•  Chapter  2,  Training  Device  Acquisition  Process,  expands 
information  on  the  processes  and  depicts  the  required  steps.  It 
contains  a  detailed  explanation  and  discussion  of  the 
interrelationships  of  the  training  developer’s  activities  and 
requirements. 

•  Chapter  3,  Nonsystem  Training  Device  Requirements 
Documentation,  provides  detailed  information  on  the 
development  of  the  nonsystem  device  requirements 
documentation.  This  chapter  includes  information  on  who 
completes  the  documentation,  the  sources  for  inputs  and  outputs, 
and  other  documentation  or  processes  used  to  provide  and/or 
collect  information.  The  NSTD  MNS  and  ORD  are  discussed  in 
this  chapter. 

•  Chapter  4,  System  Training  Device  Requirements 
Documentation,  provides  detailed  information  on  the 
development  of  system  and  training  subsystem  requirements 
documentation.  This  chapter  includes  information  on  who 
completes  the  documentation,  the  sources  for  inputs  and  outputs, 
and  other  documentation  or  processes  used  to  provide  and/or 
collect  information.  Specific  documents  covered  include  the 
system  MNS,  ORD,  and  the  ORD  Training  Support 
Requirements  (TSR)  Annex. 

•  Chapter  5,  Supporting  Documentation,  details  information  on  the 
development  of  documents  during  the  acquisition  process  to 
support  the  development  of  the  STD  and  NSTD.  These 
documents  include  the  system  training  plan  (STRAP); 
BOIP/QQPRI;  reliability,  availability,  and  maintainability  (RAM) 
data;  SMMP;  TEMP;  and  NETP. 

•  Chapter  b,  Training  Device  Studies,  provides  detailed  information 
on  the  types  of  studies  that  are  required  or  can  be  performed  on 
STDs  or  NSTDs,  the  relationships  between  the  studies,  and  the 
training  developer's  role  in  the  performance  of  these  studies. 
These  studies  include  the  cost  and  operational  effectiveness 
analysis  (COEA),  training  effectiveness  analysis  (TEA),  and  the 
concept  formulation  process. 
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Summary  (con.) 


Pertinent 
Regulations  and 
Publications 


Chapter  7,  Joint  Working  Groups,  provides  information  on  the 
interaction  of  these  elements  in  the  course  of  the  development  of 
the  device.  Emphasis  is  placed  on  those  JWGs  that  are 
specifically  oriented  toward  training  device  acquisition.  These 
working  groups  include  Training  Device  JWG,  MANPRINT  JWG, 
TIWG,  MNS  JWG,  ORD  JWG,  and  TSWG. 

Chapter  8,  Validation/Prioritization  and  Review/Approval  Process, 
outlines  information  on  those  processes  that  are  used  to 
establish  priorities  and  provide  decision  makers  with  essential 
input  for  continued  development  decisions. 

Chapter  9,  Modification  Management,  covers  information 
essential  to  the  training  developer  to  accomplish  changes  in 
documentation  and  acquisition  requirements  resulting  from 
recommended  engineering  changes  and  product  improvement 
requirements  for  all  hardware,  firmware,  and  software  changes  to 
type  classified  materiel. 

Appendix  A,  Nonsystem  Training  Device  Life  Cycle  Model, 
provides  detailed  graphic  representation  of  all  of  the  procedures 
and  steps  required  for  NSTDs.  Additionally,  the  model  provides 
references  to  the  location  within  the  procedural  guide  for  an 
explanation  of  each  step. 

Appendix  B,  System  and  Training  Subsystem  Life  Cycle  Model, 
provides  detailed  graphic  representation  of  all  of  the  procedures 
and  steps  required  for  STDs.  Additionally  the  model  provides 
references  to  the  location  within  the  procedural  guide  for  an 
explanation  of  each  step. 

Appendix  C,  Acronyms,  contains  a  list  of  the  acronyms  used  in 
this  procedural  guide. 


DODI  5000.2,  Defense  Acquisition  Management  Policies  and 
Procedures 

DOD  5000.2-M,  Defense  Acquisition  Management  Documentation  and 
Reports 

AR  70-1 ,  Army  Acquisition  Policy 

AR  71-2,  Basis  of  Issue  Plan  (BOIP)  and  Qualitative  and  Quantitative 
Personnel  Requirements  Information  (QQPRt) 

AR  350-38,  Training  Device  Policies  and  Management 
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Portinent 
Regulations  and 
Publications  (con.) 


Related  Pages 


AR  602-2,  Manpower  and  Personnel  Integration  (MANPRINT)  In  the 
Materiel  Acquisition  Process 

TRADOC  Reg  350-7,  Systems  Approach  to  Training 

TRADOC  Reg  350-32,  The  TRADOC  Training  Effectiveness  Analysis 
(TEA)  System 

TRADOC  Reg  350-40,  The  Combined  Arms  Training  Strategy 
TRADOC  Reg  351  -9,  Systems  Training  Development 


Appendix  A,  Nonsystem  Training  Device  Life  Cycle  Model,  pg.  A-1 
Appendix  B,  System  and  Training  Subsystem  Life  Cycle  Model,  pg.  B-1 
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CHAPTER  2 

TRAINING  DEVICE  ACQUISITION  PROCESS 

\ 


Training  Device  Acquisition  Process 

Overview 


Introduction 


Purpose 


Training  devices  are  developed  and  acquired  under  a  doctrine-  and 
requirements-based  process.  It  is  the  responsibility  of  the  TRADOC 
training  developer  to  identify  these  requirements  in  coordination  with  the 
combat  developer  and  materiel  developer  to  ensure  materiel  systems 
and  training  subsystems  or  NSTDs  are  developed,  procured,  and  fielded 
in  a  timely  manner. 

Training  device  development  processes  are  managed  and  monitored 
through  the  use  of  life  cycle  models.  These  models  contain  a  sequence 
of  specific  program  activities,  documentation  requirements,  and  decision 
phases  essential  to  the  U.S.  Army’s  materiel  acquisition  process.  The 
models  at  appendix  A  and  appendix  B  to  this  procedural  guide  depict 
the  normal  interactions  between  the  combat,  training,  and  materiel 
developers.  The  events  shown  are  based  on  DOD-established  practices 
for  integrated  system  and  device  fielding. 

Note  that  the  models  for  development  and  procurement  of  NSTDs  differ 
from  those  for  development  and  acquisition  of  STDs.  This  difference 
occurs  because  STDs  must  follow  the  acquisition  process  for  the 
developing  system,  whereas  NSTDs  are  separate  items  of  equipment 
and  are  developed  and  procured  independently  of  any  other  item. 

Life  cycle  models  for  development  and  acquisition  of  materiel  systems  or 
training  devices  are  not  intended  to  restrict  the  overall  acquisition 
process;  accordingly,  the  models  are  routinely  tailored  by  integrating 
data  available  from  studies  and/or  field  testing.  Tailoring  does  not 
eliminate  documentation  requirements;  however,  it  does  allow  for 
flexibility  by  combining  phases  and  milestones  and  accelerating  the 
established  process. 


This  chapter  focuses  on  the  steps  and  documentation  that  require 
training  developer  initiation  and  interaction  with  other  players  in  the 
acquisition  process.  Each  of  the  steps,  for  both  STDs  and  NSTDs,  is 
discussed  in  general  terms  to  provide  overall  information  on  each  step 
and  the  associated  actions  required.  More  specific  information  on  key 
elements  is  presented  in  subsequent  chapters  of  the  guide. 
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Two  Processes 


The  steps  associated  with  two  similar,  but  distinct,  acquisition  and  life 
cycle  processes  are  addressed  in  this  chapter.  Accordingly,  it  is 
organized  in  two  sections: 

•  Nonsystem  Training  Device  Acquisition  Process.  This  process 
begins  with  the  recognition  of  a  need  for  an  NSTD  and 
culminates  in  the  publishing  of  an  approved  operational 
requirements  document  (ORD)  and  conduct  of  an  in-process 
review  (IPR)  to  permit  development  of  the  proposed  training 
device.  This  process  is  based  on  the  Nonsystem  Training 
Device  Life  Cycle  Model  found  in  appendix  A. 

•  System  Training  Device  Acquisition  Process.  This  process 
begins  with  the  recognition  of  a  need  for  a  training  device  as  part 
of  a  new  system's  training  subsystem  and  proceeds  through  the 
development  of  all  supporting  training  documentation  for  the 
system's  ORD.  The  key  elements  in  development  and 
acquisition  of  STDs  are  to  ensure  that  the  requirements  for  the 
devices  are  documented  in  the  system’s  requirements 
documentation  and  that  a  concept  formulation  is  conducted  for 
each  device  requirement.  This  process  is  based  on  the  System 
and  Training  Subsystem  Life  Cycle  Model  found  in  appendix  B. 
Within  this  chapter  this  process  is  presented  in  two  phases 
(system  documentation  and  concept  formulation). 


2-2 


NONSYSTEM  TRAINING  DEVICE  ACQUISITION  PROCESS  OUTLINE 
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Nonsvstem  Training  Device  Acquisition  Process 


Introduction 


Definition 


Comment 


NSTDs,  like  weapon  or  equipment  systems,  are  developed  and  procured 
under  the  acquisition  guidance  and  policies  outlined  in  DODI  5000.2, 
Defense  Acquisition  Management  Policies  and  Procedures.  A 
coordinated  effort  is  essential  between  the  TRADOC  training  developer 
and  the  AMC  materiel  developer  from  the  recognition  of  an  NSTD 
requirement  throughout  the  development  and  acquisition  process  to 
ensure  the  fielded  device  provides  a  cost-  and  training-effective  solution 
to  the  identified  training  deficiency  or  issue. 


An  NSTD  is  a  device  that  supports  general  military  training.  Training 
devices  for  fielded  systems  may  also  be  documented  in  a  separate  ORD 
(like  NSTDs).  However,  funding  for  system  TADSS  remains  the 
responsibility  of  the  system  PEO/PM. 


Each  of  the  steps  of  the  NSTD  process  is  summarized  in  this  chapter. 
Starting  on  the  next  page,  specific  steps  are  highlighted  on  the  opposing 
page  to  the  text.  The  text  describes  the  NSTD  process,  which  consists 
of  1 8  interrelated  steps.  A  step  in  this  process  may  have  one  or  more 
related  elements.  For  example,  step  1 ,  "Determine  Requirement," 
consists  of  four  elements,  each  identified  as  step  1 .  This  is  because  a 
need  or  requirement  can  be  identified  by  more  than  one  source.  The 
text  for  step  1  explains  the  elements  of  the  step  to  be  followed 
depending  on  where  the  need  or  requirement  originated. 
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Step  1  The  process  of  documenting  device  requirements  begins  with  a 

Determine  recognition  of  a  need/requirement  by  the  training  community  for  a 

Requirement  training  device  as  a  cost-  and  training-effective  solution  for  a  stated 

training  deficiency.  This  need  may  be  determined  by  the  training 
developer  after  conducting  an  analysis  using  the  systems  approach  to 
training  (SAT)  process  or  may  be  proposed  by  an  individual,  unit, 
agency,  or  command.  The  analysis  process  may  include  data  from 
postfielding  studies,  other  training  studies,  command  guidance,  training 
exercises,  and  similar  sources.  This  need,  when  identified,  must 
support  a  specific  mission  need. 

If  the  requirement  is  identified  by  the  TRADOC  school  proponent,  the 
proponent  will  Integrate  the  requirement  into  the  appropriate  combined 
arms  training  strategy  (CATS).  If  a  requirement  is  identified  by  other 
than  the  school  proponent,  then  that  requirement  is  forwarded  through 
HQDA  and  TRADOC  channels  to  the  proponent  for  integration  into  the 
appropriate  CATS  and  initiation  of  the  acquisition  process.  The 
document  transmitting  the  need  may  be  a  formal  Mission  Need 
Statement  (MNS)  prepared  by  any  command  or  may  be  as  informal  as 
through  the  suggestion  award  program  or  a  memorandum  describing  a 
training  deficiency.  If  a  MNS  is  submitted  HQDA  may  approve  the 
document  then  submit  it  though  TRADOC  to  the  proponent  school  for 
development  of  an  ORD.  At  this  point  in  the  process,  what  is  important 
is  that  the  requirement  get  to  the  proponent  for  validation  and  integration 
into  the  CATS  so  that  further  acquisition  actions  can  be  initiated. 


Step  2  The  CATS  is  the  basis  for  an  integrated  training  program  that  supports 

CATS  Integration  institution  through  unit  training  requirements  and  standards.  Once  the 

requirement  has  been  determined,  the  training  developer  must  ensure 
that  it  is  incorporated  into  the  proponent’s  CATS.  All  TADSS 
requirements  must  be  included  in  CATS.  The  CATS  priority  list  is  used 
to  plan,  program,  and  budget  funds  in  support  of  research,  development, 
and  acquisition  (RDA)  requirements  and  to  adjust  program  dollars  within 
the  training  mission  area  (TMA). 
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Step  3 

Decision:  Existing 
Approved  MNS? 


Step  4 

MNS  Preparation 
and  Approval 


At  this  point  in  the  process,  formalization  of  the  program  to  develop 
and/or  procure  a  nonsystem  TADSS  begins.  An  approved  mission  need 
statement  (MNS)  is  required  to  formalize  this  process  by  permitting 
funds  to  be  expended  in  the  conduct  of  concept  studies.  These  studies 
begin  to  define  functional  requirements  for  the  proposed  TADSS  as  well 
as  identifying  alternatives  for  concept  formulation  in  meeting  the 
identified  need/requirement.  If  the  training  deficiency  that  generated  the 
requirement  is  addressed  in  an  already  approved  MNS,  the  training 
developer  may  proceed  to  step  5,  preparing  the  strawman  ORD.  If  not, 
then  a  MNS  must  be  prepared  and  forwarded  through  channels  to 
HQDA  for  approval  (step  4). 


If  an  approved  MNS  addressing  the  identified  need/requirement  is  not  in 
existence,  then  the  proponent  training  developer  must  initiate  one  at  this 
time.  The  MNS  addresses  the  training  requirement  as  a  mission  need 
and  not  as  a  hardware-specific  requirement.  The  content  and  format  for 
a  MNS  is  found  in  DOD  5000.2-M,  Defense  Acquisition  Management 
Documentation  and  Reports.  Because  this  manual  was  designed  to 
provide  guidance  for  developing  documentation  in  support  of  the 
acquisition  of  materiel  systems  as  opposed  to  training  hardware, 
additional  guidance  specific  to  TADSS  requirements  documentation  has 
been  developed  and  is  provided  in  chapter  3  of  this  procedural  guide. 

Upon  approval  of  the  MNS  by  the  proponent’s  school  commandant,  the 
training  developer  forwards  the  MNS  to  ATSC  through  the  appropriate 
integrating  command.  ATSC  staffs  the  MNS  through  HQ  TRADOC  for 
approval  by  HQDA.  ATSC  and  the  proponent  training  developer  must 
maintain  coordination  throughout  the  staffing  process  to  ensure  all 
appropriate  comments  are  incorporated  into  the  document  prior  to 
forwarding  it  to  HQDA  for  approval.  HQDA  is  the  lowest  level  of 
approval  authority  for  the  MNS. 

Subsequent  to  approval,  ATSC  distributes  the  MNS  to  the  proponent 
and  other  agencies/services  as  required.  Each  school  must  retain  a 
record  copy  of  their  approved  MNS. 
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Step  5 

Strawman  ORD 
Development 


Step  6 
Pre-JWG  1 
Coordination 


When  a  MNS  has  been  approved,  the  proponent  school  begins 
development  of  an  ORD  for  the  proposed  training  device.  The  ORD 
format,  like  the  MNS,  is  found  in  DOD  5000.2-M.  The  content  and 
format  of  an  ORD  specifically  for  nonsystem  TADSS  are  described  in 
detail  in  chapter  3  of  this  procedural  guide.  Development  of  an  ORD  in 
sufficient  detail  for  staffing  and  approval  is  an  iterative  process  that  can 
be  expected  to  take  from  six  to  nine  months.  (The  actual  time  is 
dependent  on  conduct  of  concept  formu'ation.) 

To  begin  this  interactive  process,  the  strawman  ORD  is  developed  and 
staffed  within  the  proponent  school  to  collateral  and  subordinate 
agencies  prior  to  being  forwarded  through  the  proponent’s  integrating 
command  to  ATSC.  A  system  training  plan  (STRAP)  may  be  required 
for  the  proposed  device.  ATSC,  in  conjunction  with  the  Systems 
Training  Integration  Division  (STID),  Training  Development  and  Analysis 
Directorate  (TDAD),  will  determine  whether  a  STRAP  is  required  and 
inform  the  proponent  training  developer.  If  a  STRAP  is  required,  it 
should  be  developed  concurrently  with  the  ORD  actions. 


Upon  receipt  of  the  strawman  ORD  from  the  proponent  school,  ATSC 
reviews  the  document  for  completeness  and  initiates  actions  leading  to 
joint  working  group  (JWG)  1 .  ATSC  coordinates  with  the  proponent  and 
Simulation,  Training,  and  Instrumentation  Command  (STRICOM)  to 
determine  where  and  when  the  JWG  will  take  place  as  well  as  who  will 
attend.  Copies  of  the  strawman  ORD  and  the  proposed  agenda  are 
distributed  to  all  JWG  members.  Any  agencies  or  major  Army 
commands  (MACOMs)  that  will  not  be  represented  at  the  JWG  are 
requested  to  provide  comments  to  ATSC. 
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Step  8 
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A  training  effectiveness  analysis  (TEA)  assesses  the  cost  and  training 
effectiveness  of  alternative  training  approaches  to  satisfy  a  training 
need.  ATSC  recommends  to  Deputy  Chief  of  Staff  for  Training  (DCST) 
whether  or  not  a  TEA  should  be  required.  The  recommendation  is 
based  on  an  evaluation  of  the  probable  cost,  complexity,  applicable 
technologies,  risk,  and  other  related  factors.  If  a  TEA  is  required,  ATSC 
prepares  a  study  tasker  for  the  DCST  to  send  to  the  proponent  outlining 
the  extent  of  the  necessary  TEA  actions.  The  TEA  process  continues 
through  all  subsequent  phases  of  the  device  development  process  on  an 
as-required  basis.  A  TEA,  if  conducted,  supports  the  concept 
formulation  and  must  be  completed  in  time  to  support  approval  of  the 
ORD.  Types  of  TEAs  are  explained  in  chapter  6  of  this  procedural 
guide. 

If  a  TEA  is  not  required,  ATSC  will  coordinate  for  DCST  approval  of  a 
study  waiver.  ATSC  will  forward  the  approved  waiver  to  the  proponent 
school. 


The  JWG  process,  more  than  any  other  single  element,  distinguishes 
the  training  device  acquisition  process  from  any  other  materiel 
acquisition  process.  Normally  there  will  be  at  least  two  JWGs 
conducted  during  documentation  development  for  an  NSTD.  During  this 
two-JWG  process,  the  ORD  will  progress  from  the  strawman  through  a 
fully  documented  requirements  package  that  when  approved  will  allow 
the  materiel  developer  to  proceed  to  a  request  for  proposal  (RFP) 
complete  with  technical  and  engineering  specifications. 

The  proponent  and  the  materiel  developer  (usually  STRICOM)  are  the 
chair  and  vice  chair,  respectively,  for  JWG  1 .  The  purpose  of  JWG  1  is 
to  define  the  overall  acquisition  strategy,  establish  program  milestones, 
refine  the  strawman  ORD,  and  task  appropriate  members  to  initiate 
supporting  efforts  to  complete  the  ORD  package.  These  supporting 
initiatives  and  tasks  include  but  are  not  limited  to  the  following: 

•  Develop  technical  approach  alternatives  -  AMC. 

•  Initiate  basis  of  issue  plan  (BOIP)  feeder  data  (BOIPFD)  and 
qualitative  and  quantitative  personnel  requirements  information 
(QQPRI)  -  AMC. 

•  Develop  SMMP  -  TRADOC/AMC. 

•  Refine  the  ORD  -  TRADOC/JWG  members. 
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•  Prepare/refine  operational  mode  summary/mission  profile 
(OMS/MP)  -  TRADOC. 

•  Develop  test  and  evaluation  master  plan  (TEMP)  -  AMC. 

•  Develop  Reliability,  availability,  and  maintainability  (RAM)  data  - 
TRADOC/AMC.  At  this  point  in  the  process,  RAM  data  will 
consist  of  the  parameters  required  in  the  ORD  and  the  OMS/MP. 

At  the  completion  of  JWG  1 ,  the  proponent  develops  the  draft  ORD 
based  on  the  results  of  the  JWG  and  forwards  copies  along  with  the 
minutes  of  the  meeting  to  all  attendees  and  other  interested  agencies 
and  MACOMs. 

During  the  time  between  JWG  1  (step  8)  and  JWG  2  (step  9),  the  action 
items  that  were  assigned  to  the  JWG  members  must  be  completed  so 
that  at  JWG  2  a  final  documentation  package  (the  ORD  and  all 
supporting  documentation)  can  begin  to  be  assembled  for  final  staffing 
and  the  approval  process.  The  time  frame  for  this  will  usually  be  six  to 
nine  months,  depending  on  how  long  concept  formulation  takes. 


After  concept  formulation  has  been  completed,  the  proponent  and  the 
materiel  developer  schedule  a  second  JWG.  The  purpose  of  JWG  2  is 
for  the  materiel  developer  to  present  the  technical  approach  alternatives 
and  corresponding  logistical  support  alternatives  and  for  the  proponent 
to  select  the  best  technical  approach  (BTA)  and  appropriate  logistical 
support  concept  from  these  alternatives. 

Following  selection  of  the  BTA,  JWG  2  establishes  additional  program 
milestones  and  tasks  attendees  for  final  elements  of  the  ORD 
documentation  package.  These  elements  are  the  following: 

•  Final  BOIP/QQPRI  data  -  TRADOC. 

•  TEA  data  -  TRADOC. 

•  Completed  RAM  rationale  report  (RRR)  -  CASCOM. 

•  TEMP  -  AMC/TRADOC. 

•  Refined  CATS  -  TRADOC. 
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Approximately  three  months  after  JWG  2  (after  tasking  actions  are 
completed),  the  proponent  assembles  the  final  draft  ORD  package  for 
staffing.  The  ORD  package  is  forwarded  through  the  proponent’s 
integrating  command  to  ATSC.  The  RRR  is  approved  by  the  Combined 
Arms  Support  Command  (CASCOM)  and  a  summary  of  the  report  is 
included  with  the  ORD  package.  Approval  of  the  RRR  is  required  prior 
to  a  recommendation  of  ORD  approval  by  the  Training  Device 
Requirements  Review  Committee  (TDRRC)  (step  12). 


Upon  receipt,  ATSC  staffs  the  ORD  package  with  HQDA  and  HQ 
TRADOC  staff  elements,  the  MACOMs,  other  sen/ices,  and  other 
TRADOC  schools  as  appropriate.  Upon  completion  of  staffing,  if  no 
major  changes  are  required,  the  ATSC  action  officer  prepares  the 
package  for  presentation  to  the  TDRRC  (step  12).  If  major  revisions  are 
necessary,  the  package  must  be  returned  to  the  proponent  for 
appropriate  action. 

All  comments  received  from  this  staffing  will  be  addressed  in  a 
coordination  annex  to  the  ORD.  A  rationale  will  be  provided  for  those 
comments  that  were  not  accepted. 


The  completed  ORD  package  is  referred  to  the  TDRRC  for  final  review 
and  recommendation  for  approval.  The  TDRRC  ensures  that  the  ORD 
and  its  supporting  documentation  meet  all  regulatory  requirements  and 
are  administratively  correct  and  that  the  ORD  is  ready  to  be  sent  to  the 
approval  authority. 

ATSC  chairs  the  TDRRC.  Committee  membership  and  responsibilities 
can  be  found  in  chapter  8  of  this  procedural  guide. 


Upon  recommendation  for  approval  by  the  TDRRC,  ATSC  forwards  the 
documentation  package  to  the  approval  authority.  Approval  of  training 
device  ORDs  is  normally  at  the  TRADOC/AMC  level.  Some  major 
TADSS  items  may  require  HQDA-level  approval.  In  any  case  ATSC  will 
coordinate  the  approval  process,  and  the  proponent  school  will  be 
provided  a  copy  of  the  final  approved  document. 
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Concurrently  with  the  ORD  development  and  approval  process,  the 
materiel  developer  develops  the  IPR  package  for  a  milestone  decision. 
Although  the  ORD  has  been  approved,  device  development  cannot 
proceed  until  a  milestone  decision  permits.  The  materiel  developer 
conducts  the  IPR.  The  decision  authority  is  at  the  AMC  level  or  higher. 

The  materiel  developer  recommends  the  direction  of  the  program  to  the 
decision  authority.  TRADOC  may  concur  with  these  recommendations, 
concur  with  modifications,  or  nonconcur.  A  TRADOC  position  will  be 
determined  after  review  of  the  materiel  developer’s  IPR  package.  The 
TRADOC  IPR  position  is  established  by  ATSC  (step  15). 


Upon  receipt  of  the  IPR  package  from  STRICOM,  ATSC  prepares  a 
recommended  TRADOC  position  for  the  IPR. 


The  materiel  developer  conducts  the  IPR,  as  explained  in  step  14.  If  the 
TRADOC  position,  is  in  complete  concurrence  with  the  materiel 
developer,  then  no  further  action  is  required  by  the  proponent,  ATSC,  or 
TRADOC.  If  the  TRADOC  position  varies  from  the  materiel  developer's 
position,  then  representation  by  ATSC  and/or  TRADOC  may  be  required 
to  defend  the  TRADOC  position  at  the  formal  IPR. 


The  materiel  developer  prepares  a  statement  of  work  (SOW)  for  a 
requests  for  proposal  (RFP)  to  industry  for  development  and  acquisition 
of  the  training  device.  Both  the  proponent  and  ATSC  must  review  this 
SOW  to  ensure  that  the  device  requirements  being  presented  to  industry 
match  the  requirements  that  were  delineated  in  the  ORD. 


After  review  and  approval  of  the  SOW  by  the  proponent  and  ATSC,  the 
materiel  developer  will  release  the  RFP  to  industry. 
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After  the  materiel  developer  awards  the  contract  for  the  device,  the 
training  developer  is  not  finished  with  developmental  actions.  A  review 
of  the  model  for  developing  nonsystem  devices  at  appendix  A  will  show 
that  more  actions  are  left  to  be  accomplished  in  the  NSTD  development 
and  acquisition  process.  These  actions  include  developing  test  plans, 
conducting  tests,  evaluating  the  device  after  fielding,  and  developing 
requests  under  the  materiel  change  management  process  if  required. 
This  will  ensure  that  when  the  device  is  fielded  users  will  be  able  to 
operate  and  maintain  the  device  to  its  maximum  capability. 


DOD  5000.2-M,  Defense  Acquisition  Management  Documentation  and 
Reports 

AR  70-1 ,  Army  Acquisition  Policy 

AR  71  -2,  Basis  of  issue  Plan  (BOiP)  and  Qualitative  and  Quantitative 
Personnel  Requirements  Information  (QQPRI) 

AR  350-38,  Training  Device  Policies  and  Management 

AR  602-2,  Manpower  and  Personnel  Integration  (MANPRINT)  in  the 
Materiel  Acquisition  Process 

TRADOC  Reg  350-7,  Systems  Approach  to  Training 

TRADOC  Reg  350-32,  The  TRADOC  Training  Effectiveness  Analysis 
(TEA)  System 

TRADOC  Reg  350-40,  The  Combined  Arms  Training  Strategy 
TRADOC  Reg  351-9,  Systems  Training  Development 


Nonsystem  Training  Device  Mission  Need  Statement,  pg.  3-4 

Nonsystem  Training  Device  Operational  Requirements  Document, 

pg.  3-9 


System  Training  Plan,  pg.  5-5 

Basis  of  Issue  Plan/Qualitative  and  Quantitative  Personnel 
Requirements  Information,  pg.  5-9 


Related  Pag*  (con.) 


System  MANPRINT  Management  Plan,  pg.  5-23 

Testing  and  Evaluation,  pg.  5-28 

Training  Effectiveness  Analysis  Process,  pg.  6-8 

Concept  Formulation,  pg.  6-12 

Training  Device  Joint  Working  Group  Process,  pg.  7-3 

Other  Joint  Working  Groups,  pg.  7-13 

Modification  Management,  pg.  9-1 
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System  Training  Device  Acquisition  Process 


Introduction 


Definition 


U.S.  Army  policy  dictates  the  fielding  of  total  systems.  The  term  “total 
system"  refers  to  a  materiel  system  that,  when  fielded,  is  complete  with 
all  training  and  support  subsystems.  In  order  to  develop  total  systems, 
close  coordination  throughout  the  development  cycle  is  required 
between  combat,  training,  and  materiel  developers. 

The  process  of  identifying  and  procuring  training  support  items 
(embedded  training,  devices,  simulators,  and  simulations)  for  emerging 
systems  is  a  process  within  a  process.  Put  another  way,  a  training 
device  is  a  materiel  item.  As  such,  development  and  acquisition  of  this 
materiel  item  must  be  accomplished  in  accordance  with  all  procurement 
policies  and  regulations.  The  item  must  also  be  acquired  within  the 
system's  acquisition  program.  The  training  developer  must  work  within 
the  constraints  of  the  materiel  acquisition  strategy  for  the  system  but  at 
the  same  time  must  identify,  develop,  test,  and  procure  training  support 
items.  The  process  for  obtaining  these  items  is  very  similar  to  that  used 
to  acquire  NSTDs  with  one  notable  exception:  STDs  do  not  have  their 
own  requirements  documentation  (MNS  or  ORD).  Requirements  for 
training  support  items  must  be  documented  in  the  system  MNS  and 
ORD  and  in  supporting  documentation.  This  information  map  presents  a 
synopsis  of  how  the  training  developer  ensures  the  appropriate  training 
hardware  can  be  developed  and  procured  for  emerging  systems  without 
the  formal  documentation  required  for  the  acquisition  of  NSTDs. 

The  training  developer  must  remain  cognizant  of  the  fact  that  although  a 
separate  MNS  and  ORD  are  not  required  for  the  development  and 
procurement  of  STDs,  all  requirements  for  supporting  documentation  are 
still  applicable  to  ensure  cost-  and  training-effective  TADSS  are 
developed  and  procured. 


An  STD  is  a  device  that  supports  training  for  a  specific  weapon  or 
equipment  system.  These  devices  are  normally  documented, 
developed,  and  procured  concurrently  with  the  materiel  system. 
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Comment 


The  overall  acquisition  process  for  materiel  systems  and  training 
subsystems  is  outlined  in  the  System  and  Training  Subsystem  Life  Cycle 
Model  at  appendix  B.  This  information  map  presents  the  process  by 
which  STD  requirements  are  integrated  into  the  materiel  system 
acquisition  process.  Starting  on  the  next  page,  specific  steps  are 
highlighted  on  the  opposing  page  to  the  text.  The  text  describes  the 
system  documentation  process  and  the  system  TADSS  concept 
formulation  process,  which  results  in  appropriately  documented 
requirements  for  system  training  device  requirements.  The  general 
process  of  the  system  TADSS  concept  formulation  is  very  similar  to  the 
process  for  development  and  acquisition  of  NSTDs  with  the  exception  of 
the  specific  documentation  required. 

Each  of  the  steps  of  the  system  documentation  process  and  the  system 
TADSS  concept  formulation  process  is  summarized  in  this  chapter.  The 
system  documentation  process  begins  with  the  identification  of  a  need 
or  requirement  for  a  new  materiel  system  and  proceeds  through 
approval  of  the  system  ORD  and  conduct  of  a  milestone  I  IPR.  The 
system  TADSS  concept  formulation  process  may  begin  at  or  after  the 
system's  milestone  0  decision  and  proceeds  through  release  of  an  RFP 
for  device  development/procurement.  To  distinguish  between 
documentation  steps  and  concept  formulation  steps,  the  steps  are 
identified  with  a  "D"  for  documentation  or  a  “CF"  for  concept  formulation. 
A  step  in  either  process  may  have  one  or  more  related  elements.  For 
example,  step  1-D,  "Determine  Requirements,"  consists  of  four 
elements,  each  identified  as  step  1-D.  This  is  because  the  requirement 
can  be  identified  by  more  than  one  source.  The  text  for  step  1  -D 
explains  the  elements  of  the  step  to  be  followed  depending  on  where 
the  requirement  originated. 
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Step  1-0  The  requirement  for  a  new  materiel  system  is  determined  through  a 

Determine  concept-  and  doctrine-based  process.  It  is  a  continuing  process  that 

Requirement  considers  such  factors  as  war-fighting  capabilities  and  deficiencies,  the 

existing  and  emerging  threat,  current  doctrine  and  future  concepts,  fiscal 
constraints,  and  the  emergence  of  new  technology.  Recommendations 
for  the  solutions  to  war-fighting  capability  issues  are  sought  in  the 
domains  of  doctrine,  training,  leader  development,  organization  or 
materiel.  Improvements  in  soldier  performance,  which  transcends  all 
other  domains,  is  always  of  utmost  consideration.  The  combat 
developer  at  the  proponent  TRADOC  school  is  the  one  most  likely,  in 
the  course  of  ongoing  studies  and  analyses,  to  recognize  a  war-fighting 
capability  issue  and  to  recommend  a  solution;  but,  requirements  can  be 
identified  by  any  command,  agency,  or  individual.  When  the  need  for  a 
new  or  modified  materiel  system  to  meet  a  specific  mission  need  has 
been  identified,  the  planning  for  justifying  and  documenting  this  need  is 
initiated  through  conduct  of  a  formal  or  informal  early  comparability 
analysis  (ECA). 

If  a  requirement  is  identified  by  other  than  the  school  proponent,  then 
that  requirement  is  forwarded  through  HQ  DA  and  TRADOC  channels  to 
the  proponent  for  initiation  of  the  acquisition  process.  The  document 
transmitting  the  need  may  be  a  formal  Mission  Need  Statement  (MNS) 
prepared  by  any  command  or  may  be  as  informal  as  through  the 
suggestion  award  program  or  a  memorandum  describing  a  battlefield 
deficiency.  If  a  MNS  is  submitted  HQDA  may  approve  the  document 
then  submit  it  though  TRADOC  to  the  proponent  school  for  development 
of  an  ORD.  At  this  point  in  the  process,  what  is  important  is  that  the 
requirement  get  to  the  proponent  for  validation  so  that  acquisition 
actions  can  be  initiated. 


Step  2-D  Upon  determination  of  a  need  for  a  new  or  modified  materiel  system,  the 

Initiate  Early  proponent  combat  developer  will  initiate  an  ECA.  The  ECA  is  a 

Comparability  scientific  analysis  of  predecessor  and  reference  systems  conducted  to 

Analysis  (ECA)  capitalize  on  lessons  learned  from  previously  fielded  systems  in  order  *o 

influence  design  parameters  of  a  new  system. 

•  A  predecessor  system  is  a  system  or  item  of  equipment  that 
currently  exists  that  has  been  targeted  for  replacement  or 
product  improvement. 
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Step  2-0 
Initiate  Early 
Comparability 
Analysis  (ECA) 
(con.) 


Step  3-0 
MANPRINT  JWG 


•  A  reference  system  is  a  system  or  components  of  existing 
systems  that  can  be  found  in  current  inventories  to  meet  or 
closely  approximate  the  mission  requirements  of  a  newly 
proposed  system  or  component. 

The  proponent  training  developer  uses  the  results  of  the  ECA  to  develop 
an  initial  training  concept  to  prepare  for  the  manpower  and  personnel 
integration  (MANPRINT)  JWG  (MJWG)  and  development  of  the  system 
MANPRINT  management  plan  (SMMP)  (step  3-D).  This  information  is 
also  used  to  input  training  requirements  and  constraints  to  the  system 
MNS  (step  4-D).  Additional  information  on  the  ECA  can  be  found  in  the 
Training  Developers’  Procedural  Guide  for  Identifying  Requirements  for 
System  Training  Devices.  If  a  formal  ECA  is  not  conducted  for  a  new 
system,  the  training  developer  should  still  follow  the  thought  process 
associated  with  the  ECA  to  develop  an  initial  training  concept. 


After  the  combat  developer  has  determined  that  a  new  materiel  system 
will  be  required  and  preliminary  data  is  available  from  the  ECA,  an 
MJWG  is  convened.  MANPRINT  is  a  comprehensive  technical  effort  to 
support  system  effectiveness  by  integrating  into  the  materiel 
development  and  acquisition  process  all  relevant  information: 

•  Human  factors  engineering. 

•  Manpower. 

•  Personnel. 

•  Training  and  training  devices. 

•  System  safety. 

•  Health  hazards. 

These  elements  are  referred  to  as  the  six  domains  of  MANPRINT.  At 

this  JWG,  members  develop  the  SMMP.  The  SMMP  is  a  dynamic 
planning  and  management  document  used  by  all  activities  involved  in 
the  materiel  development  and  acquisition  process  to  ensure  that  the  six 
domains  of  MANPRINT  are  addressed  throughout  the  system's  life 
cycle.  The  SMMP  is  updated  as  required  throughout  system 
development. 
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Step  4-0 
MNS  Preparation 


Step  5-D 

Staff  and  Approve 
MNS 


Step  6-0 
Initiate  STRAP 


At  this  point  in  the  process,  formalization  of  the  program  to  develop 
and/or  procure  a  new  materiel  system  begins  to  take  place.  An 
approved  MNS  is  required  to  formalize  this  process  and  establish  a 
management  decision  package  (MDEP)  to  permit  the  programming  and 
expenditure  of  funds  to  conduct  concept  studies.  The  content  and 
format  for  a  MNS  is  found  in  DOD  5000.2M,  Defense  Acquisition 
Management  Documentation  and  Reports.  The  proponent  combat 
developer  prepares  the  MNS  with  assistance  from  the  training 
developer.  Training  developer  input  to  the  MNS  is  general  in  nature  and 
centers  around  constraints  associated  with  system  training  requirements. 
Broad  training  concepts  are  established  at  this  time  for  eventual  input  to 
the  STRAP  (step  6-D)  and  the  training  support  requirements  (TSR) 
annex  to  the  ORD  (step  7-D). 


Upon  approval  of  the  MNS  by  the  proponent’s  school  commandant,  the 
combat  developer  forwards  it  through  the  appropriate  integrating 
command  to  HQ  TRADOC  for  staffing  and  final  approval  by  HQDA. 
HQDA  is  the  lowest  level  of  approval  authority  for  the  MNS. 

Approval  of  the  MNS  constitutes  a  milestone  0  approval,  allowing  the 
system  to  enter  concept  exploration  and  definition  (phase  0)  of  the  life 
cycle  model.  (See  appendix  B.) 


The  STRAP  is  one  of  the  most  important  documents  for  which  the 
training  developer  will  be  responsible  in  the  materiel  system 
development  and  acquisition  process.  The  STRAP  is  the  master 
training  plan  for  a  new  system.  It  documents  the  results  of  early  training 
analyses  and  specifically  addresses  who  requires  training,  what  tasks 
need  to  be  trained,  and  when,  where,  and  how  the  training  will  be 
conducted.  Training  concepts  and  strategies  in  the  STRAP  are  used  as 
input  to  the  system  requirements  documentation.  The  STRAP  is  an 
evolving  document  that  is  updated  before  each  milestone  decision 
review  (MDR)  throughout  the  system’s  development  and  any  time  that 
training  concepts  or  strategies  change. 
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Stop  7-0 

Prepare  and  Staff 
ORD  and  TSR 
Annex 


Step  8-0 
COEA/TEA 


Step  9-0 
Staff  ORD 


Upon  approval  of  the  MIMS,  the  proponent  combat  developer,  in 
conjunction  with  the  training  developer  and  the  materiel  developer, 
prepares  an  ORD.  The  ORD  concisely  states  the  essential  operational, 
technical,  logistic,  training  support,  and  cost  parameters  necessary  to 
initiate  the  development  and/or  procurement  of  the  system.  The  training 
developer  must  maintain  close  coordination  with  the  combat  developer 
during  ORD  preparation  to  ensure  training  and  training  support 
requirements  are  documented  in  the  system  ORD.  Once  the  ORD  is 
approved,  funding,  including  that  for  training  support  items,  becomes 
more  defined. 

Training  requirements  identified  in  the  ORD  are  detailed  in  a  TSR 
annex.  This  annex  includes  specific  requirements  for  embedded  training 
and  TADSS.  It  is  essential  that  the  training  developer  identify  TADSS 
requirements  in  this  annex.  Requirements  for  TADSS  that  are  not 
documented  in  the  TSR  annex  at  ORD  approval  mav  have  to  be 
developed  and  procured  under  a  separate  ORD  for  each  device. 

The  ORD  is  staffed  through  the  proponent's  integrating  command  to  HQ 
TRADOC,  where  It  will  be  further  staffed  with  appropriate  commands 
and  agencies  (step  9-D). 


Concurrently  with  ORD  preparation,  the  combat  developer  conducts  a 
cost  and  operational  effectiveness  analysis  (COEA).  The  COEA  is  a 
comparative  analysis  of  alternative  means  of  meeting  a  need  or 
requirement  and  the  cost  of  developing,  producing,  distributing,  and 
sustaining  each  alternative  In  a  military  environment. 

As  part  of  the  COEA,  the  training  developer  conducts  a  TEA.  The  TEA 
is  an  analysis  conducted  to  compare  alternative  training  concepts  and 
strategies  for  the  proposed  new  system.  Requirements  for  embedded 
training  and  TADSS  can  be  derived  from  the  TEA  and  documented  in 
the  ORD  and  TSR  annex. 


Upon  receipt  of  the  ORD  by  HQ  TRADOC,  the  DCSCD  staffs  the 
document  with  appropriate  commands  and  agencies  for  comments. 
Recipients  of  the  ORD  will  be  invited  to  provide  comments  and/or  attend 
a  JWG  (step  1 1  -D)  to  discuss  and  finalize  the  documentation. 
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Step  10-0 

Prepare  Supporting 
Documentation 


Step  11-D 
ORD  JWG 


Step  12-D 
Finalize  ORD 


While  the  ORD  is  in  the  staffing  process,  combat,  materiel,  and  training 
developers  initiate  the  supporting  documentation.  Supporting 
documentation  must  be  finalized  prior  to  the  Requirements  Review 
Committee’s  recommendation  for  approval  (step  13-D).  The  following 
are  the  major  documents  supporting  the  ORD: 

•  Basis  of  issue  plan  (BO IP)  and  qualitative  and  quantitative 
personnel  requirements  information  (QQPRI). 

•  Test  and  evaluation  master  plan  (TEMP). 

•  New  equipment  training  plan  (NETP). 

•  System  manprint  management  plan  (SMMP). 

•  System  training  plan  (STRAP). 

•  Reliability,  availability,  and  maintainability  (RAM)  rationale  report. 

Not  only  must  this  supporting  documentation  be  finalized  to  obtain  a 
recommendation  for  ORD  approval,  but  it  also  directly  impacts  the  IPR 
package  prepared  by  the  materiel  developer  for  a  milestone  I  decision 
(step  14-D). 


A  JWG  is  a  group  of  representatives  from  the  combat,  materiel,  and 
training  development  communities  and  selected  subject  matter  experts 
providing  a  forum  for  direct  communication  to  facilitate  the  coordination 
of  requirements  documentation  and  related  actions  in  the  materiel 
acquisition  process.  After  staffing  of  the  ORD  has  been  completed,  the 
proponent  combat  developer  convenes  a  JWG  to  finalize  the  ORD  and 
assign  follow-on  actions.  It  is  essential  that  the  training  developer 
attend  and  become  active  in  the  JWG  to  ensure  all  training  requirements 
are  addressed  in  the  documentation. 


Comments  and  recommendations  from  the  JWG  are  included  in  the 
documentation,  and  a  final  ORD  is  prepared  for  the  proponent  school 
commandant’s  approval  and  forwarded  through  the  proponent’s 
integrating  command  to  DCSCD.  At  this  time,  the  training  developer 
must  again  ensure  that  all  training  requirements  are  addressed  in  the 
basic  documentation  and  included  in  the  TSR  Annex. 
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Step  13-D 
Requirements 
Review  Committee 
(RRC) 


Step  14-D 
ORD  Approval 


Step  15-D 
IPR  Package 
Development 


Upon  receipt  of  the  final  ORD  package  from  the  proponent,  the  DCSCD 
convenes  the  RRC.  The  committee  ensures  documents  are  complete 
and  that  they  clearly  state  the  required  essential  characteristics  of  the 
system  in  a  manner  that  will  allow  the  materiel  developer  to  proceed 
with  an  RFP  for  industry  to  design  and  develop  the  system. 

Training  representation  to  the  RRC  is  provided  by  the  DCST  at  HO 
TRADOC  to  ensure  training  subsystem  requirements,  including  testing, 
are  addressed  appropriately  in  the  documentation. 

After  validation  of  the  requirement  and  agreement  that  the 
documentation  is  complete  and  adequately  defines  the  requirement,  the 
RRC  recommends  approval  and  forwards  the  package  to  the 
appropriate  approval  authority. 


The  ORD  is  approved  either  by  TRADOC  and  AMC,  HQDA,  or  DOD  as 
appropriate.  The  approval  authority  is  determined  based  on  the 
acquisition  category  (ACAT)  under  which  the  developmental  program 
falls.  An  explanation  of  ACATs  can  be  found  in  chapter  1  of  this 
procedural  guide  and  in  appropriate  DOD  directives  and  U.S.  Army 
regulations.  The  HQDA  or  DOD  acquisition  executive  assigns  the  ACAT 
at  the  beginning  of  the  program  (milestone  0). 


Concurrently  with  the  ORD  development  and  approval  process,  the 
materiel  developer  develops  the  IPR  package  for  a  milestone  I  decision. 
Although  the  ORD  has  been  approved,  the  system  development  cannot 
proceed  until  a  milestone  I  decision  permits.  The  materiel  developer 
conducts  the  IPR  to  obtain  this  decision.  The  decision  authority  is  at  the 
HQ  AMC  level  or  higher. 

The  materiel  developer  recommends  the  direction  of  the  program  to  the 
decision  authority.  TRADOC  may  concur  with  these  recommendations, 
concur  with  modifications,  or  nonconcur.  A  TRADOC  position  will  be 
made  after  review  of  the  materiel  developer’s  IPR  package.  (Step 
16-D). 
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Step  16-0 
TRADOC  IPR 
Position 


Upon  receipt  of  the  IPR  package  from  the  materiel  developer,  DCSCD 
prepares  a  recommended  TRADOC  position  for  the  IPR. 


Step  17-D 
Conduct  IPR 


System  Process  - 

Documentation 

Summary 


The  materiel  developer  conducts  the  IPR,  as  explained  in  step  15.  If  the 
TRADOC  position  is  in  complete  concurrence  with  the  materiel 
developer,  then  no  further  action  is  required  by  the  proponent,  DCSCD, 
or  HQ  TRADOC.  If  the  TRADOC  position  varies  from  the  materiel 
developer’s  position,  then  representation  by  TRADOC  may  be  required 
at  the  formal  IPR. 


This  has  been  a  brief  explanation  of  the  documentation  process  for  a 
new  materiel  system.  More  detailed  discussions  of  the  training 
developer's  involvement  in  this  process  and  related  documentation  can 
be  found  in  the  appropriate  chapters  of  this  procedural  guide.  There  are 
three  major  points  for  the  training  developer  to  remember  about  this 
process: 

•  Begin  interaction  with  the  combat  developer  as  early  in  the 
process  as  possible.  This  will  ensure  that  TADSS  requirements 
are  included  in  the  system  documentation. 

•  Develop  a  comprehensive  STRAP  and  update  it  whenever 
training  strategies  change  and  before  each  MDR.  A  well 
thought-out  STRAP  captures  and  keeps  current  the  iraining 
information  required  in  other  documents. 

•  Be  an  active  participant  in  all  phases  of  the  system 
documentation  process  to  ensure  training  and  training  support 
items  are  developed  and  procured  with  the  system. 

The  remainder  of  this  information  map  addresses  a  process  within  the 
system  development  and  acquisition  process:  conducting  concept 
formulation  for  those  TADSS  that  were  documented  as  requirements  for 
the  training  subsystem. 
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Each  training  device  to  be  developed  and/or  procured  for  the  proposed 
materiel  system  will  require  its  own  concept  formulation  to  be  performed. 
The  data  package,  prepared  by  the  proponent  and  forwarded  to  ATSC, 
must  contain  sufficient  information  about  the  proposed  training  device  to 
allow  the  materiel  developer  (usually  STRICOM)  to  begin  concept 
formulation  and  develop  the  materiel  developer’s  IPR  package.  Since 
the  required  data  may  exist  in  many  forms,  there  is  no  specific  format 
for  the  data  package.  For  a  complete  list  of  the  required  items  to  be 
addressed  in  the  data  package,  see  "Training  Device  Requirements 
Data  Package"  in  chapter  4  of  this  procedural  guide. 


Upon  receipt  of  the  data  package  from  the  proponent  school,  ATSC 
reviews  the  document  and  prepares  the  JWG  read-ahead  package  for 
all  participants  of  JWG  1 .  This  entails  providing  copies  of  the  data 
package  and  the  proposed  agenda  to  all  JWG  members.  Any  agencies 
or  MACOMs  that  will  not  be  represented  at  the  JWG  are  requested  to 
provide  comments  to  ATSC. 


A  TEA  assesses  the  cost  and  training  effectiveness  of  alternative 
training  approaches  to  satisfying  a  training  requirement.  The 
recommendation  is  based  on  an  evaluation  of  the  probable  cost, 
complexity,  applicable  technologies,  risk,  and  other  related  factors.  If  a 
TEA  is  required,  ATSC  prepares  a  study  tasker  for  the  DCST  to  send  to 
the  proponent  outlining  the  extent  of  the  necessary  TEA  actions.  The 
TEA  process  continues  through  all  subsequent  phases  of  the  device 
development  process  on  an  as-required  basis.  A  TEA,  if  conducted, 
supports  the  concept  formulation  and  must  be  completed  in  time  to 
support  approval  of  the  training  device  requirements  data  package. 
Types  of  TEAs  are  explained  in  chapter  6  of  this  procedural  guide. 


If  a  TEA  is  not  required,  ATSC  wilt  coordinate  for  DCST  approval  of  a 
study  waiver.  ATSC  will  forward  the  approved  waiver  to  the  proponent. 


SYSTEM  TADSS  ACQUISITION  PROCESS  OUTLINE 


Step  4-CF 
Conduct  JWG  1 


Step  5-CF 
Update/Revise 
CATS  Strategies 


The  JWG  process,  more  than  any  other  single  element,  distinguishes 
the  training  device  acquisition  process  from  any  other  materiel 
acquisition  process.  Normally  there  will  be  at  least  two  JWGs 
conducted  during  the  concept  formulation  of  each  STD.  During  this  two- 
JWG  process,  the  requirements  data  package  will  progress  from  a  draft 
(not  all  information  is  yet  known  about  the  proposed  device)  through  a 
fully  documented  requirements  package  that,  when  complete,  will  allow 
the  materiel  developer  to  proceed  to  an  I  PR  and  subsequent  release  of 
an  RFP  complete  with  technical  and  engineering  specifications. 

The  proponent  and  the  materiel  developer  (usually  STRICOM)  are  the 
chair  and  vice  chair,  respectively,  for  JWG  1 .  The  purpose  of  JWG  1  is 
to  define  the  overall  acquisition  strategy,  establish  program  milestones, 
and  task  appropriate  members  to  initiate  supporting  efforts  to  complete 
the  requirements  data  package.  These  supporting  initiatives  and  tasks 
include  but  are  not  limited  to  the  following: 

•  Develop  technical  approach  alternatives. 

•  Develop  TEMP. 

•  Develop  RRR. 

•  Conduct  TEA. 

At  the  completion  of  JWG  1 ,  action  items  for  the  completion  of  the  data 
package  are  assigned  to  the  JWG  members.  The  minutes  of  the 
meeting  are  provided  to  all  attendees  and  other  interested  agencies  and 
MACOMs. 

During  the  time  between  JWG  1  and  JWG  2  (step  7-CF),  the  action 
items  that  were  assigned  to  the  JWG  members  must  be  completed  so 
that  at  JWG  2  a  final  requirements  data  package  (including  all 
supporting  documentation)  can  begin  to  be  assembled  for  final  staffing 
and  review  by  the  TDRRC.  The  time  frame  for  this  will  usually  be  six  to 
nine  months,  depending  on  how  long  concept  formulation  takes. 


All  TADSS  requirements  must  be  included  in  the  proponent’s  functional 
CATS  and  updated/revised  as  the  situation  warrants.  These  updates 
will  directly  affect  the  system  ORD  and  TSR  annex  as  well  as  supporting 
documentation  and  TADSS  concept  formulation.  Chapter  8  contains 
additional  information  regarding  CATS. 
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SYSTEM  TADSS  ACQUISITION  PROCESS  OUTLINE 


Step  6-CF 
Conduct  Concept 
Formulation 


Step  7-CF 

Develop  Supporting 
Documentation 


After  JWG  1,  the  materiel  developer,  in  conjunction  with  the  training 
developer,  can  begin  conducting  the  concept  formulation.  Remember 
that  each  training  device  requires  its  own  concept  formulation. 

However,  if  a  requirements  data  package  for  more  than  one  training 
device  was  presented  at  the  JWG,  the  concept  formulations  may  be 
conducted  concurrently.  The  concept  formulation  analyzes  and 
evaluates  available  and  emerging  technology  to  meet  the  requirements 
as  defined  in  the  requirements  data  package.  These  technologies  are 
considered  candidates  for  device  development  and  are  evaluated  in 
terms  of  cost,  training  effectiveness,  degree  of  developmental  risk,  and 
constraints  placed  on  the  system  and/or  device  training  strategies.  At 
JWG  2  the  best  of  these  candidate  technologies  will  be  selected  as  the 
best  technical  approach  as  weighed  against  each  of  the  factors.  For  a 
complete  description  of  the  concept  formulation,  see  chapter  6  of  this 
procedural  guide. 

Note  in  the  diagram  on  the  opposing  page  that  a  dashed  arrow  is  drawn 
between  step  6-CF  and  step  7-CF.  This  is  to  show  that  the  concept 
formulation  has  a  direct  impact  on  the  completion  of  supporting 
documentation.  Until  the  best  technical  approach  has  been  selected, 
and  other  documentation  that  relies  on  a  technological  selection  cannot 
be  completed. 


Supporting  documents  to  the  requirements  data  package  must  be 
developed  to  allow  the  materiel  developer  to  complete  the  I  PR  package 
and  technical  specifications  for  an  RFP.  Each  document  and  the 
agency  primarily  responsible  for  its  development  are  listed  below: 

•  RRR  -  proponent/CASCOM. 

•  BOI P/distribution  plan  -  proponent. 

•  Refined  CATS  -  proponent. 

•  Concept  formulation  data  supporting  the  BTA  -  materiel 
developer. 

•  Integrated  logistic  support  plan  (ILSP)  -  materiel  developer. 

•  TEMP  -  materiel  developer. 

•  NETP  -  materiel  developer. 

•  TEA  -  proponent. 
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SYSTEM  TADSS  ACQUISITION  PROCESS  OUTLINE 


Step  7-CF 

Develop  Supporting 

Documentation 

(con.) 


Step  8-CF 
Conduct  JWG  2 


Step  9-CF 
Assemble/Forward 
Final  Requirements 
Data  Package 


Step  10-CF 

Staff  and  Integrate 

Comments 


Step  11-CF 
Conduct  TDRRC 


More  detailed  information  regarding  this  documentation  can  be  found  in 
the  appropriate  sections  of  this  procedural  guide. 


After  concept  formulation  has  been  completed,  the  proponent  and  the 
materiel  deveioper  schedule  a  second  JWG.  The  purpose  of  JWG  2  is 
for  the  materiel  developer  to  present  the  technical  approach  alternatives 
and  corresponding  logistical  support  alternatives  and  for  the  proponent 
to  select  the  best  technical  approach  (BTA)  and  appropriate  logistic 
support  concept. 

Following  selection  of  the  BTA,  JWG  2  establishes  additional  program 
milestones  and  tasks  attendees  for  final  elements  of  the  requirements 
data  package. 


Once  tasking  actions  are  completed  after  JWG  2,  the  proponent 
assembles  the  final  requirements  data  package  for  staffing.  The  data 
package  is  forwarded  through  the  proponent’s  integrating  command  to 
ATSC.  Concurrently,  a  copy  of  the  RRR  is  approved  by  the  CASCOM 
and  a  summary  of  the  report  is  included  with  the  requirements  data 
package.  The  RRR  must  be  approved  prior  to  a  recommendation  for 
approval  of  the  data  package  by  the  TDRRC  (step  11-CF). 


Upon  receipt,  ATSC  staffs  the  requirements  data  package  with  HQ 
TRADOC  staff  elements,  the  MACOMs,  other  services,  and  TRADOC 
schools  as  determined  appropriate.  Upon  completion  of  staffing,  if  no 
major  changes  are  required,  the  ATSC  action  officer  prepares  the 
package  for  presentation  to  the  TDRRC  (step  11-CF).  If  major  revisions 
are  necessary,  the  package  must  be  returned  to  the  proponent  for 
appropriate  action. 


The  completed  requirements  data  package  is  referred  to  the  TDRRC  for 
final  review.  The  TDRRC  serves  as  the  user  representative  for  review, 
validation,  and  processing  of  all  training  device  requirements 
documentation.  The  committee  ensures  documents  are  complete  and 
that  they  clearly  state  the  type  of  device  needed  to  support  training  and 
enhance  combat  readiness. 
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ATSC  Conducts 
TDRRC 


13-CF 


ATSC  Develops 
the  TRADOC  IPR 
Position 


14-CF 


Conduct  IPR  I/ll 
or  l/lll  as 
Appropriate 


Step  11-CF 
Conduct  TDRRC 
(con.) 


Step  12-CF 
IPR  Package 
Development 


Step  13-CF 
TRADOC  IPR 
Position 


Step  14-CF 
Conduct  IPR 


ATSC  chairs  the  TDRRC.  Chapter  8  of  this  procedural  guide  explains 
committee  membership  and  their  responsibilities. 


Concurrently  with  the  data  package  development  and  approval  process, 
the  materiel  developer  develops  the  IPR  package  for  a  milestone 
decision.  Although  the  data  package  has  been  approved,  the  STD 
development  program  cannot  proceed  until  a  milestone  I  decision 
permits.  The  materiel  developer  conducts  the  IPR  to  obtain  this 
decision.  The  decision  authority  is  at  the  HQ  AMC  level  or  higher. 

The  materiel  developer  recommends  the  direction  of  the  program  to  the 
decision  authority.  TRADOC  may  concur  with  these  recommendations, 
concur  with  modifications,  or  nonconcur.  A  TRADOC  position  will  be 
made  after  review  of  the  materiel  developer’s  IPR  package.  (Step 
13-CF). 


Upon  receipt  of  the  IPR  package  from  STRICOM,  ATSC  prepares  a 
recommended  TRADOC  position  for  the  IPR. 


The  materiel  developer  conducts  the  IPR,  as  explained  in  step  12-CF.  If 
the  TRADOC  position  is  in  complete  concurrence  with  the  materiel 
developer’s  position,  then  no  further  action  is  required  by  the  proponent, 
ATSC,  or  TRADOC.  If  the  TRADOC  position  varies  from  the  materiel 
developer’s  position,  then  representation  by  ATSC  and/or  TRADOC  may 
be  required  at  the  formal  IPR. 
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Step  15-CF 
Review  Statement 
of  Work 


Step  16-CF 
RFP/Contract  Award 


Actions  After 
System  TADSS  - 
Contract  Award 


Pertinent 
Regulations  and 
Publications 


The  materiel  developer  prepares  an  SOW  for  an  RFP  to  industry  for 
development  and  acquisition  of  the  training  device.  Both  the  proponent 
and  ATSC  must  review  this  SOW  to  ensure  that  the  device  requirements 
being  presented  to  industry  match  the  requirements  that  were  delineated 
in  the  requirements  data  package. 


After  review  and  approval  of  the  SOW  by  the  proponent  and  ATSC,  the 
materiel  developer  will  release  the  RFP  to  industry.  There  are  times 
when  the  award  of  the  contract  will  not  be  competitive.  For  example,  if 
the  prime  contractor  (the  contractor  developing  the  system)  also  has  the 
capability  to  produce  the  required  training  hardware,  the  system  program 
manager  (PM)  or  program  executive  officer  (PEO)  may  permit  that 
contractor  to  produce  the  training  devices  without  further  competition. 
Conversely,  the  PM/PEO  may  decide  that  it  is  to  the  government’s 
advantage  to  compete  the  development  of  the  device  openly  within 
industry. 


Although  the  contract  award  completes  the  concept  formulation  process 
for  the  development  and  acquisition  of  system  TADSS,  the  training 
developer  is  not  finished  with  developmental  actions.  A  review  of  the 
model  for  developing  systems  and  training  subsystems  at  appendix  B 
will  show  that  many  actions  and  much  coordination  are  left  to  be 
accomplished  in  the  STD  development  and  acquisition  process. 

Training  subsystems  should  be  developed  and  tested  concurrently  with 
the  systems  that  they  support.  This  will  ensure  that  when  new  or 
modified  systems  are  fielded  into  the  Army  inventory,  users  will  be  able 
to  operate  and  maintain  the  systems  to  their  maximum  capacity  and 
enhance  combat  readiness. 


DOD  5000.2-M,  Defense  Acquisition  Management  Documentation  and 
Reports 

AR  70-1 ,  Army  Acquisition  Policy 

AR  71  -2,  Basis  of  Issue  Plan  (BOIP)  and  Qualitative  and  Quantitative 
Personnel  Requirements  Information  (QQPRI) 

AR  350-38,  Training  Device  Policies  and  Management 
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Pertinent 
Regulations  and 
Publications  (con.) 


Related  Pages 


AR  602-2,  Manpower  and  Personnel  Integration  (MANPRINT)  In  the 
Materiel  Acquisition  Process 

TRADOC  Reg  350-7,  Systems  Approach  to  Training 

TRADOC  Reg  350-32,  The  TRADOC  Training  Effectiveness  Analysis 
(TEA)  System 

TRADOC  Reg  350-40,  The  Combined  Arms  Training  Strategy 
TRADOC  Reg  351  -9,  Systems  Training  Development 


System  Mission  Need  Statement,  pg.  4-4 
System  Operational  Requirements  Document,  pg.  4-9 
Annex  C,  Training  Support  Requirements,  pg.  4-20 
Training  Device  Requirements  Data  Package,  pg.  4-26 
System  Training  Plan,  pg.  5-5 

Basis  of  Issue  Plan/Qualitative  and  Quantitative  Personnel 
Requirements  Information,  pg.  5-9 

Reliability,  Availability,  and  Maintainability,  pg.  5-17 

System  MANPRINT  Management  Plan,  pg.  5-23 

Testing  and  Evaluation,  pg.  5-28 

New  Equipment  Training  Plan,  pg.  5-34 

Cost  and  Operational  Effectiveness  Analysis,  pg.  6-4 

Concept  Formulation,  pg.  6-12 

Training  Device  Joint  Working  Group  Process,  pg.  7-3 

Other  Joint  Working  Groups,  pg.  7-13 

Validation/Prioritization  and  Review  Approval  Process,  pg.  8-1 

Modification  Management,  pg.  9-1 
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CHAPTER  3 


NONSYSTEM  TRAINING  DEVICE 
REQUIREMENTS  DOCUMENTATION 


Nonsystem  Training  Device  Requirements  Documentation 

Overview 


Introduction 


Documenting  the 
Requirement 


Comment 


Mission  Need 
Statement  (MNS) 


The  need  for  a  new  or  improved  NSTD  may  be  proposed  by  any 
individual,  unit,  agency,  or  command.  Chapter  2  provides  an  overview 
of  the  process  for  the  development  and/or  acquisition  of  NSTDs.  This 
chapter  provides  detail  on  the  documentation  required  to  initiate  the 
materiel  acquisition  process  in  relation  to  research,  development,  and 
acquisition  of  NSTDs.  it  addresses  only  the  primary  documents  needed 
to  support  the  need  and  requirement.  Supporting  documentation  is 
found  in  chapter  5. 


There  are  two  primary  documents  that  are  essential  to  the  development 
and  acquisition  of  NSTDs: 

•  Mission  need  statement  (MNS). 

•  Operational  requirements  document  (ORD) 


Although  detailed  information  regarding  supporting  documentation  is  not 
presented  in  this  chapter,  training  developers  should  be  cognizant  of  the 
fact  that  requirements  documentation  will  not  be  approved  without  these 
supporting  documents.  Close  coordination  with  other  players  in  the 
materiel  acquisition  process  must  be  maintained  throughout  the  process, 
and  all  documentation  must  be  completed  at  appropriate  points  in  the 
process  before  device  development  and  acquisition  can  begin  or 
proceed. 


The  MNS  is  the  initiating  document  for  any  materiel  acquisition  program. 
The  proponent  training  developer  prepares  the  NSTD  MNS  with  input 
from  the  materiel  developer.  The  MNS  does  not  propose  a  materiel 
solution  to  the  stated  need  but  rather  addresses  a  training  requirement 
as  a  mission  need.  HQDA  approval  of  the  MNS  constitutes  a  milestone 
0  decision  and  permits  the  conduct  of  conceptual  studies  to  determine 
alternative  solutions  to  meeting  the  stated  need. 
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Operational 
Requirements 
Document  (ORD) 


The  ORD  describes  the  operational  parameters  for  a  proposed  NSTD. 
The  training  developer  prepares  the  ORD  with  input  from  the  materiel 
developer  and  many  other  players  in  the  materiel  acquisition  process 
(logisticians,  testers,  users).  ORD  development  is  an  iterative  process, 
requiring  close  and  constant  coordination  throughout  the  process.  When 
approved,  the  device  acquisition  program  may  proceed  to  a  Milestone  I 
(or  I/ll  or  l/lll)  decision  permitting  continuation  of  the  acquisition  program. 


Supporting 

Documentation 


Supporting  documentation  required  for  approval  of  NSTD  requirements 
documentation  will  be  mentioned  throughout  this  chapter.  The  level  of 
detail  for  these  documents  varies  depending  on  the  complexity,  cost,  or 
basis  of  issue  of  the  proposed  device.  The  following  are  some  of  the 
primary  supporting  documents  associated  with  the  development  and 
acquisition  of  NSTDs: 

ORD  annexes 

•  Annex  A,  Rationale. 

•  Annex  B,  Coordination. 

•  Annex  C,  Training  Device  Strategy. 

Other  supporting  documentation 

•  System  MANPRINT  management  plan  (SMMP). 

•  Test  and  evaluation  master  plan  (TEMP). 

•  Basis  of  issue  plan  (BOIP)/qualitative  and  quantitative  personnel 
requirements  information  (QQPRI). 

•  System  training  plan  (STRAP). 

•  Distribution  plan. 

•  Reliability,  availability  and  maintainability  (RAM)  rationale  report. 

•  Training  effectiveness  analysis  (TEA). 

Additional  information  on  this  supporting  documentation  can  be  found  in 
chapter  5. 
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Pertinent 
Regulations  and 
Publications 


Related  Pages 


DOD  5000.2-M,  Defense  Acquisition  Management  Documentation  and 
Reports 

AR  350-38,  Training  Device  Policies  and  Management 


Nonsystem  Training  Device  Mission  Need  Statement,  pg.  3-4 

Nonsystem  Training  Device  Operational  Requirements  Document, 

pg.  3-9 


Testing  and  Evaluation,  pg  5-28 


Nonsvstem  Training  Device  Mission  Need  Statement 


Introduction 


Purpose 


Process 


When  a  training  deficiency  has  been  identified,  determination  and 
documentation  of  the  best  possible  solution  are  required.  Identification 
of  a  need  may  result  from  a  number  of  sources,  such  as  an  analysis  of 
training  programs  or  mission  performance,  feedback  from  trainers  in  the 
field,  or  training  tests  and  exercises.  If  an  NSTD  is  determined  as  the 
best  probable  solution  to  the  identified  deficiency,  then  the  training 
developer  must  begin  the  documentation  to  permit  funds  to  be  identified 
for  conceptual  studies.  The  documentation  required  to  initiate  such  a 
program  is  the  MNS. 


The  NSTD  MNS  has  three  main  purposes: 

•  Document  an  identified  mission  need  that  cannot  be  satisfied  by 
a  nonmateriel  solution. 

•  Provide  essential  information  necessary  to  complete  the 
Determination  of  Mission  Need  phase  in  the  NSTD  life  cycle 
management  process. 

•  Permit  the  expenditure  of  funds  for  the  conduct  of  conceptual 
studies  of  alternative  solutions  to  solve  the  stated  need. 


When  a  training  or  performance  deficiency  has  been  identified  and  a 
nonmateriel  solution  does  not  appear  to  be  the  most  cost-  and  training- 
effective  course  of  action,  the  proponent  training  developer  incorporates 
the  requirement  into  CATS  and  determines  if  an  existing  approved  MNS 
documents  the  need.  If  an  approved  MNS  does  not  exist  to  support 
development  of  requirements  documentation,  then  the  training  developer 
initiates  MNS  development. 

If  a  new  MNS  is  required,  the  training  developer  prepares  the  MNS, 
coordinates  it  with  other  schools  as  appropriate,  and  forwards  it  through 
the  integrating  command  to  ATSC  for  HQ  TRADOC  staffing.  ATSC 
obtains  TRADOC  and  HQ  DA  approval  and  notifies  the  proponent  of 
MNS  approval. 
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Process  (con.) 


NSTD  MNS 
Content/Format 


The  NSTD  MNS  is  not  to  exceed  five  pages  in  length  and  consists  of 
five  paragraphs.  Additional  information  to  help  explain  or  define  Ihe 
need  may  be  appended  to  the  basic  document. 


MISSION  NEED  STATEMENT  (MNS) 

1.  Defense  Planning  Guidance  Element 

2.  Mission  and  Threat  Analysis 

3.  Nonmateriel  Alternatives 

4.  Potential  Materiel  Alternatives 

5.  Constraints 
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Paragraph  1 
Defense  Planning 
Guidance 


Paragraph  2 
Mission  and  Threat 
Analyses 


Paragraph  3 
Nonmateriel 
Alternatives 


Paragraph  4 
Potential  Materiel 
Alternatives 


In  this  paragraph  the  training  developer  must  assess  the  U.S.  Army 
and/or  TRADOC  long  range  training  plan  and  identify  the  major 
program(s)  to  which  the  need  responds,  for  example,  supports  home 
station  training  for  the  active  and  reserve  components.  The  training 
developer  must  also  reference  the  functional  training  strategy(ies)  within 
the  CATS  that  the  proposed  training  capability/need  supports. 
Subparagraphs  may  be  used  as  necessary  to  address  these  information 
elements. 


The  training  developer  uses  this  paragraph  to  describe  the  specific 
training  need  or  deficiency  upon  which  the  identified  requirement  is 
based.  This  need  must  be  defined  in  terms  of  training  objectives  and 
general  capabilities.  The  need  is  not  developed  or  defined  in  terms  of 
equipment  or  specific  performance  objectives.  The  training  developer 
must  also  Identify  the  war-fighting  capabilities  that  resulted  from  the 
continuing  doctrine  and  requirements  review  process.  A  primary  source 
for  identification  of  these  capabilities  is  the  battlefield  development  plan 
(BDP)  that  is  maintained  by  HQ  TRADOC. 

Paragraph  2  must  also  contain  a  detailed  description  of  the  contribution 
the  training  objective  will  make  in  terms  of  achieving  the  related  war¬ 
fighting  capability.  Further  requirements  of  this  paragraph  include 
comments  on  the  timing  and  general  priority  of  the  identified  need 
relative  to  others  in  the  designated  functional  area.  Subparagraphs  may 
be  used  as  necessary  to  provide  this  information. 


In  this  paragraph  the  training  developer  must  provide  information  and 
rationale  as  to  why  nonmateriel  alternatives  are  inappropriate  or 
inadequate  to  achieve  the  identified  training  need.  Nonmateriel 
considerations  include  potential  change  in  current  operational  doctrine, 
concepts,  tactics,  training,  or  organizational  structure.  Subparagraphs 
may  be  used  as  necessary  to  cover  this  information. 


This  paragraph  contains  a  description  of  any  known  training  systems  or 
programs  capable  of  meeting  the  proposed  need  that  have  been 
developed,  are  under  development,  or  are  in  production  by  other 
services  or  allied  nations.  It  also  discusses  the  potential  for  interservice 
applications  or  allied  cooperation  that  may  apply  to  the  development 
process. 
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Paragraph  4 
Potential  Materiel 
Alternativea  (con.) 


Paragraph  5 
Constraints 


Pertinent 
Regulations  and 
Publications 


This  paragraph  also  is  used  to  indicate  any  potential  areas  of  study  in 
the  Concept  Exploration  and  Definition  phase  where  existing  U.S.  allied 
military  or  commercial  training  systems  or  product  improvements  may 
have  application.  This  data  is  not  used  for  evaluation  of  these  potential 
alternatives.  This  data  is  for  identification  of  possible  solutions  only. 
Subparagraphs  are  used  as  necessary  to  include  this  information. 


The  training  developer  uses  this  paragraph  to  describe  any  constraints 
that  may  impact  on  solutions  responding  to  the  developing  need: 

•  Logistics  support. 

•  Transportation. 

•  Power  sources. 

•  Manpower,  personnel,  training  constraints,  human  factors, 

system  safety,  and  health  hazards. 

•  Communications  and/or  software  and  hardware  interface. 

•  Security. 

•  Standardization  or  interoperability  with  other  services  or  allied 

nations. 

Also  included  in  this  paragraph  is  a  discussion  of  the  operational/training 
environments  in  which  the  proposed  training  capability  is  to  be  used.  If 
these  are  different,  the  level  of  desireu/required  capability  in  these 
environments  is  defined,  for  example,  the  level  of  training  that  is 
required  for  reserve  and  active  component  training  or  garrison  versus 
deployed  environments.  Subparagraphs  may  be  used  as  necessary  to 
address  this  information,  especially  in  the  case  of  Manpower  and 
Personnel  Integration  (MANPRINT)  considerations. 


DODI  5000.?  Defense  Acquisition  Management  Policies  and 
Procedures 

DOD  5000. 2-M,  Defense  Acquisition  Management  Documentation  and 
Reports 

AR  70-1,  Army  Acquisition  Policy 

AR  350-38,  Training  Device  Policies  and  Management 
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Rotated  Pagos 


Training  Effectiveness  Analysis  Process,  pg.  6-8 
Combined  Arms  Training  Strategy,  pg.  8-5 
Modification  Management,  pg.  9-1 
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Nonsvstem  Training  Device 
Operational  Requirements  Document 


Introduction 


Purpose 


Upon  approval  of  the  NSTD  MNS,  the  proponent  begins  preparation  of 
an  ORD.  The  ORD  will  define  a  materiel  requirement  as  a  solution  to 
the  stated  need.  Development  of  the  NSTD  ORD  is  an  iterative  process 
involving  training  developers,  materiel  developers,  testers,  logisticians, 
and  others  providing  information  from  the  user  community. 

The  training  developer,  with  input  from  the  materiel  developer  and 
others,  is  responsible  for  preparing  the  NSTD  ORD.  Since  the  ORD  is 
the  document  that  will  be  the  basis  for  a  request  for  proposal  (RFP)  for 
development  and  procurement,  it  is  imperative  to  clearly  define  the 
requirements  of  the  device.  Developers  and  end  item  users  must  be 
given  sufficient  information  to  facilitate  comprehensive  planning  to 
support  fielding  of  the  device  and  integration  into  existing  training 
programs. 


The  NSTD  ORD  has  four  main  purposes: 

•  Provide  the  materiel  developer  with  the  minimum  acceptable 
device  requirements,  capabilities,  and  operational  standards 
needed  to  meet  the  MNS. 

•  Alert  the  materiel  development  and  training  communities  to 
anticipated  logistics  support  for  the  proposed  training  device. 

•  Distribute  advance  planning  information  regarding  training 
requirements  and  criteria  associated  with  operation  and 
maintenance  of  the  proposed  device. 

•  Allow  a  milestone  I/ll  decision  to  permit  the  training  device 
acquisition  program  to  proceed  to  phases  I  and  II,  Demonstration 
and  Validation/Engineering  and  Manufacturing. 
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Process 


Preparation  of  the  NSTD  ORD  is  an  iterative  process.  This  process  will 
result  in  a  strawman  ORD,  Draft  ORD,  final  draft  ORD,  and  Final  ORD. 
The  NSTD  joint  working  group  (JWG)  process  in  chapter  7  provides 
additional  details  on  the  iterative  developmental  process.  The  iterative 
development  of  this  document  occurs  because  as  the  device  proceeds 
through  life  cycle  development,  additional  data  on  each  of  the  key 
elements  of  the  document  emerges,  allowing  continuous  updates. 

The  end  result  of  this  document  development  process  is  a  final  ORD. 
Concurrently  with  the  NSTD  ORD  development  and  update  processes, 
the  required  annexes  are  initiated  and  refined.  The  NSTD  ORD 
development  process  is  shown  below. 


Strawman  ORD  The  training  developer  initiates  the  process  by  developing  the  strawman 

Actions  ORD  based  on  the  need  identified  in  the  NSTD  MNS.  If  a  STRAP  is 

required,  ATSC  informs  the  proponent,  and  the  training  developer 
begins  the  STRAP  development  at  this  time. 

At  this  point,  the  ORD  is  staffed  internally  in  the  proponent  school  to 
interested/affected  agencies.  Staffing  structure  and  procedures  may 
vary  from  school  to  school.  Internal  standing  operating  procedures 
(SOPs)  contain  this  information. 

When  the  document  has  completed  internal  staffing  and  all  comments 
are  incorporated,  the  proponent  forwards  the  strawman  ORD  through 
the  integrating  command  to  ATSC. 
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Strawman  ORD 
Actions  (con.) 


Draft  ORD  Actions 


Final  Draft  ORD 
Actions 


ATSC  reviews  the  document  for  completeness  and  prepares  the  read- 
ahead  package  for  the  JWG  1 .  This  package  includes  a  copy  of  the 
strawman  ORD  and  instructions  for  conduct  of  the  JWG.  Additional 
information  is  at  Chapter  7,  JWG  Process. 

Concurrently  with  the  staffing  action,  ATSC  makes  a  determination 
regarding  the  requirement  for  the  program  and/or  the  level  of  study  effort 
needed  to  support  the  program.  The  Deputy  Chief  of  Staff  for  Training 
(DOST)  issues  to  the  proponent  a  study  directive  (if  required)  outlining 
the  study  actions  to  be  taken.  When  JWG  1  actions  have  been 
completed,  the  JWG  will  result  in  publication  of  the  draft  ORD. 


During  the  time  between  JWG  1  and  JWG  2,  a  number  of  critical  actions 
related  to  continued  development  of  the  device  documentation  are  in 
progress.  These  include  but  are  not  limited  to  the  following: 

•  The  materiel  developer  Simulation,  Training  and  Instrumentation 
Command  (STRICOM)  conducts  concept  formulation  for  the 
device. 

•  The  SMMP  is  drafted  based  on  discussion  and  task  assignment 
in  the  JWG. 

•  The  TEMP,  to  include  critical  operational  issues  and  criteria 
(COIC),  is  developed  and  documented. 

•  The  BOIP/QQPRI  is  developed. 

•  The  training  strategy  is  updated  and  refined. 

•  Ongoing  study  processes  are  continued. 

The  key  factor  for  conduct  of  JWG  2  and  further  action  on  device 
development  is  the  status  of  the  concept  formulation.  Once  STRICOM 
has  completed  the  concept  formulation,  JWG  2  can  take  place.  At  this 
point  in  the  process,  the  training  developer  ensures  that  all  interim 
action  items  are  completed  and  that  the  requirements  documents  are 
current.  The  product  resulting  from  these  actions  is  a  final  draft  ORD. 


The  final  draft  ORD  and  available  supporting  documentation  comprise 
the  ORD  package.  The  training  developer  is  responsible  for  staffing  this 
package  with  other  schools.  ATSC  accomplishes  subsequent  staffing  to 
major  commands,  HQ  TRADOC,  and  other  agencies  as  designated. 
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Final  Draft  ORD 
Actions  (con.) 


Final  ORD  Actions 


NSTD  ORD 
ContanVFormat 


When  all  comments  have  been  received  from  the  staffing  process,  the 
coordination  a.  'ex  (annex  B)  of  the  ORD  is  developed.  This  annex 
contains  a  list  ot  all  comments  submitted  during  the  staffing  process  that 
were  not  accepted  for  inclusion  into  the  document.  Rationale  for 
nonacceptance  of  comments  is  also  provided  in  annex  B. 


Once  the  coordination  annex  is  developed  and  revision  of  the  base 
documents  (with  submitted  comments)  is  completed,  the  final  ORD  is 
submitted  to  ATSC  for  review.  Prior  to  continuing  on  in  the  approval 
process,  ATSC  reviews  the  document,  and  it  is  submitted  to  the  Training 
Device  Requirements  Review  Committee  (TDRRC).  (Additional 
information  on  the  TDRRC  process  is  In  chapter  6.) 

When  the  TDRRC  document,  it  is  submitted  for  final  approval.  The 
approval  authority  is  normally  TRADOC  and  AMC;  however,  for  some 
programs  higher  level  approval  may  be  required. 


The  ORD  consists  of  eight  paragraphs  with  subparagraphs  as  applicable 
to  fully  define  the  requirement.  The  completed  ORD  package  also 
includes  three  annexes. 


OPERATIONAL  REQUIREMENTS  DOCUMENT  (ORD) 

1 .  General  Description  of  Operational  Capability 

2.  Threat 

3.  Shortcomings  of  Exisitng  Systems 

4.  Capabilities  Required 

5.  Integrated  Logisitic  Support  (ILS) 

6.  Infrastructure  Support  and  Interoperability 

7.  Force  Structure 

8.  Schedule  Considerations 


RATIONALE 


Annex  A 


COORDINATION 


Annex  B 


TRAINING  DEVICE  STRATEGY 


Annex  C 
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Paragraph  1 
General  Desc  Iption 
of  Operational 
Capability 


Paragraph  2 
Threat 


Paragraph  3 
Shortcomings  of 
Existing  Systems 


Paragraph  4 
Capabilities 
Required 


The  training  developer  uses  paragraph  1  to  identify  the  mission  area(s) 
that  the  proposed  device  supports  and  to  provide  sufficient  detail  in  the 
description  to  initiate  program  and  logistic  planning.  This  paragraph  also 
describes  how  the  device  fits  into  the  CATS.  The  OMS/MP,  the  training 
device  strategy  (annex  C  of  the  ORD),  and  the  CATS  must  be  in 
agreement  a»*  J  mutually  supportive. 


The  training  developer  identifies  the  battle  lab  that  the  device  or 
simulation  supports.  This  paragraph  also  describes  the  contribution  of 
the  device  in  terms  of  achieving  war-fighting  and  training  capabilities.  A 
review  of  the  information  contained  in  paragraph  2  of  the  MNS  may 
assist  in  developing  this  data.  The  war-fighting  capabilities  identified  in 
paragraph  2  of  the  MNS  must  be  contained  in  this  paragraph. 


This  paragraph  must  describe  why  existing  training  systems  or  programs 
cannot  meet  current  or  projected  training  requirements.  The  training 
developer  substantiates  the  data  for  this  paragraph  by  discussing/ 
reviewing  those  programs  or  devices  identified  in  paragraph  4  of  the 
MNS  and  explaining  why  they  do  not  meet  the  need.  Factors  that  are 
addressed  include  why  the  present  method  of  training  is  no  longer 
cost/training  effective  and  what,  if  any,  cost  savings  or  trade-offs  of  other 
resources  will  be  realized  upon  fielding  of  the  proposed  training  device; 
for  example,  use  of  this  device  will  reduce  the  OPTEMPO  by  10  rounds 
of  tank  main  gun  ammunition  per  crew  per  year. 


In  paragraph  4  the  training  developer  identifies  those  essential 
characteristics  and  performance  capabilities  required  for  the  proposed 
device.  These  are  stated  in  operational  terms,  prioritized,  if  possible, 
and  delineated  in  three  subparagraphs:  System  Performance,  Logistics 
and  Readiness,  and  Critical  System  Characteristics. 

Each  performance  parameter  is  specified  in  terms  of  a  minimum 
acceptable  value  (threshold)  required  to  satisfy  the  training  mission  need 
and  a  performance  objective.  The  objective  should  represent  a 
measurable,  beneficial  increase  in  training  capability,  operations,  and 
support  above  the  threshold.  A  listing  of  the  rationale  for  each  critical 
performance  characteristic  developed  is  attached  at  Annex  A,  Rationale. 
Characteristic  and  performance  capabilities  submitted  without  a 
corresponding  rationale  will  not  be  accepted. 
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Paragraph  4 
Capabilities 
Required  (con.) 


Paragraph  5 
Integrated  Logistics 
Support  (ILS) 


4.a.  System  Performance  -  includes  any  device  performance 
parameters  that  affect  the  training  requirement  such  as  throughput 
requirements,  engagement  ranges,  weapon  system/hardware 
characteristics  to  be  emulated  or  simulated,  interface  requirements  with 
other  training  systems,  and/or  existing  operational  equipment.  Describe 
mission  scenarios  (wartime  and  peacetime)  in  terms  of  mission  profiles, 
employment  tactics,  and  environmental  conditions. 

4.b.  Logistics  and  Readiness  -  contains  any  RAM  requirements 
identified  for  the  device.  It  also  identifies  any  system  support 
requirements  or  constraints  for  maintenance  and/or  replacement 
requirements.  It  is  used  to  describe  the  expected  maintenance 
manpower  and  skill  level's  availability  as  a  MANPRINT  constraint. 
MANPRINT  information  may  be  incorporated  in  paragraph  5.c.  if  the 
issue  requires  detailed  explanation. 

4.c.  Critical  System  Characteristics  -  addresses  natural  environmental 
factors  (such  as  climatic,  terrain,  and  oceanographic  factors), 
electromagnetic  compatibility,  and  frequency  assignment  for  training 
systems  operating  in  the  electromagnetic  spectrum.  It  also  defines  the 
expected  mission  capability  (for  example,  full  or  percentage  of 
degradation  in  the  identified  environments),  identifies  any  physical  and 
operational  security  needs,  and  defines  and  addresses  any  critical 
physical  characteristics  such  as  height,  weight,  etc. 


The  training  developer  uses  the  following  subparagraphs  to  address  any 
organizational,  intermediate,  depot-level,  or  contractor  logistical  support 
objectives  for  initial  operational  capability  and  full  operational  capability 
(IOC/FOC)  achievement. 

5.a.  Maintenance  Planning  -  contains  all  identified  maintenance  support 
tasks  and  provides  the  rationale  for  selecting  contract  logistic  support 
versus  organic  maintenance  repair. 

5.b.  Support  Equipment  -  defines  the  standard  support  equipment 
required  by  the  training  device.  It  also  describes  the  test  and  fault 
isolation  capabilities  desired  of  any  automatic  test  equipment  required 
and  the  applicable  level  of  maintenance.  This  subparagraph  also 
identifies  the  need  for  special  tools  or  test  equipment  or  constraints 
associated  with  the  requirement. 

5.c.  Human  Systems  Integration  -  identifies  the  manpower,  personnel, 
training,  human  factors  engineering,  system  safety,  and  health  hazards 
constraints.  These  are  extracted  from  the  "Issues"  section  of  the  SMMP 
and  presented  in  summary  form. 
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Paragraph  5 
Integrated  Logistics 
Support  (ILS)  (con.) 


Paragraph  6 
Infrastructure 
Support  and 
Interoperability 


Manpower  limitations  in  the  force  structure  for  military  and  civilian 
operators,  instructors,  and  maintainers  are  also  defined.  Analytical 
methodologies,  such  as  hardware  versus  manpower  (HARDMAN) 
comparability,  that  are  or  were  used  to  determine  manpower,  personnel, 
or  training  impacts  for  the  device  should  be  explained  even  though  they 
are  not  part  of  the  ORD.  This  subparagraph  is  used  to  address  any 
other  MANPRINT  constraints,  objectives,  or  thresholds  that  are  not 
covered  in  other  ORD  areas. 

5,d.  Computer  Resources  -  contains  information  on  special  requirements 
and  potential  constraints  occurring  in  this  functional  area.  Examples 
include  specific  language(s),  data  base  architecture,  and  interoperability 
considerations.  This  subparagraph  also  addresses  all  mission-critical 
and  support  resources  and  automated  test  equipment  and  describes  the 
capabilities  desired  or  required  for  recurring  computer  resource  support. 

The  training  developer  uses  this  element  to  identify  and  inp-.it  details  on 
any  unique  user  interface  requirements,  documentation  needs,  special 
software  certifications,  configuration  management,  postdeployment 
software  support,  and  anticipated  frequency  of  software  changes  and/or 
system  upgrades. 

5.e.  Other  Logistics  Considerations  -  describes  the  provisioning  strategy 
for  the  device.  Any  unique  facility  and  shelter  requirements  are 
specified.  Special  packaging,  handling,  and  transportation 
considerations  are  identified.  Unique  data  requirements  such  as 
engineering  data  for  depot  support  of  the  device  or  supporting 
equipment  are  defined. 


The  training  developer  uses  the  subparagraphs  outlined  on  the  next 
page  to  discuss  any  interfacing  systems  at  the  system/subsystem, 
platform,  and  force  levels.  Specifically  addressed  are  those  systems 
related  to  command,  control,  communications,  and  intelligence  (C3I); 
transportation  and  basing;  and  standardization  and  interoperability. 
Information  in  this  paragraph  and  subparagraphs  must  identify  any  other 
ORD  and/or  other  services  that  may  have  similar  requirements.  If 
applicable,  a  joint  potential  designation  (joint,  joint  interest,  or 
independent)  must  be  assigned. 
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Paragraph  6  6.a.  Command,  Control,  Communication,  and  Intelligence  •  information 

Infrastructure  describes  how  the  training  device  will  support  and  integrate  with  the  C3I 

Support  and  architecture  that  is  expected  to  exist  at  the  time  the  proposed  device  is 

Interoperability  fielded.  This  description  includes  any  data  requirements  (data,  voice, 

(con.)  and  video),  computer  network  support,  and  antijamming  requirements.  It 

also  identifies  any  unique  intelligence  information  requirements  including 
intelligence  interfaces,  communications,  and  data  base  support 
requirements  to  support  the  conduct  of  training  with  or  without  the 
proposed  device.  These  information  elements  are  provided  as 
applicable. 

6.b.  Transportation  and  Basing  -  describes  how  the  device  will  be 
moved  to  or  within  the  training  environment.  Deployability  of  training 
devices  in  support  of  mobile  forces  is  a  consideration  and  must  be 
addressed  in  this  and  other  appropriate  paragraphs.  The  normal 
institutional,  home  station,  local,  and  major  training  area  locations  of 
training  devices  may  become  less  viable  if  the  target  audience  is 
deployed  to  an  operational  area  with  specific  and  continuing  training 
requirements. 

This  subparagraph  aiso  identifies  any  setup  and/or  takedown  constraints 
and  special  lift  requirements,  to  include  description  of  facilities,  required 
to  support  normal  use  and  storage  of  the  training  device.  Requirements 
for  new  permanent  construction  routinely  take  up  to  five  years  to 
accomplish.  Accordingly,  if  a  requirement  for  a  special  facility  exists, 
this  information  must  be  identified  and  documented  as  early  as  possible 
in  the  process. 

6.c.  Standardization,  Interoperability,  and  Commonality  -  identifies 
considerations  for  joint  use  of  the  device.  This  subparagraph  also 
includes  information  regarding  any  procedural  and  technical  interfaces, 
communications,  protocols,  and  standards  required  to  ensure 
interoperability  with  other  services,  joint  service,  and  allied  training 
systems.  This  subparagraph  also  addresses  energy  standardization  and 
efficiency  needs  for  fuels  and  electrical  power  as  applicable. 

6.d.  Mapping,  Charting,  and  Geodesy  Support  -  identifies  cartographic 
materials,  digital  topographic  data,  and  geodetic  input  required  to 
support  training  device  employment.  Where  possible,  Defense  Mapping 
Agency  standard  military  data  will  be  used. 

6.e.  Environmental  Support  -  identifies  any  standard  or  unique  weather, 
oceanographic,  and  astrogeophysical  support  requirements.  This  data 
must  include  accuracy  and  forecast  frequency  specifications. 
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Paragraph  7 
Force  Structure 


Paragraph  8 

Schedule 

Considerations 


Annex  A 
Rationale 


Annex  B 

Coordination  Annex 


The  training  developer  uses  this  paragraph  to  identify  and  estimate  the 
number  of  training  devices  that  wili  be  required  including  spares  and 
quantities  needed  to  support  other  services’  or  government  agencies. 
This  information  is  used  to  assist  in  the  development  of  essential 
elements  of  information  for  the  training  device  strategy  at  annex  E.  This 
data  is  included  in  the  MANPRINT  requirements  related  to  the  proposed 
device. 


This  paragraph  defines  the  events  and  actions  required  to  attain  IOC 
and  FOC.  The  preliminary  schedule  should  reflect  sufficient  flexibility  for 
revisions  as  the  program  is  progressively  defined  and  trade-off  studies 
are  completed.  This  scheduling  effort  must  also  clearly  specify  the  level 
of  performance  or  capability  necessary  to  reach  IOC  or  FOC.  Included 
are  the  number  of  training  devices,  operational  and  support  personnel, 
facilities,  and  maintenance  support  that  must  be  in  place. 

If  device  availability  in  a  specific  time  frame  is  critical,  the  milestone 
objective  for  IOC  is  specified  and  the  impact  if  this  objective  is  not 
achieved  is  described.  A  window  of  acceptability  is  provided  if 
appropriate.  Subparagraphs  and  milestone  schedules  should  be  used 
as  necessary  to  address  this  information. 


The  rationale  annex  supports  each  of  the  essential  characteristics  that 
were  developed  for  the  device  and  documented  in  paragraph  4 
(Capabilities  Required)  of  the  ORD.  Each  essential  characteristic 
element  identified  must  have  a  corresponding  rationale  statement. 
Characteristics  that  do  not  have  a  rationale  will  not  be  accepted. 

Annex  A  will  also  include  a  synopsis  of  the  executive  summary  of  the 
approved  RAM  rational  report  (RRR). 


The  coordination  annex  is  used  to  document  all  comments  that  were 
received  during  staffing  of  the  ORD  that  were  not  accepted  for  inclusion 
into  the  document.  Each  comment  that  is  not  accepted  by  the 
proponent  must  have  a  corresponding  justification  for  its  nonacceptance. 
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Annex  C 
Training  Device 
Strategy 


Commercially 
Available  Devices 


Supporting 

Documentation 


Pertinent 
Regulations  and 
Publications 


Annex  C,  by  title  and  content,  is  a  highly  critical  document  in  the  overall 
device  development  process.  This  document  is  comprised  of  two 
paragraphs  with  device-specific  substantiating  information: 

•  Paragraph  1  is  a  listing  of  all  individual  and  collective  tasks  that 
are  associated  with  training  the  device. 

•  Paragraph  2  is  a  comprehensive  narrative  covering  the 
information  developed  regarding  how  the  device  is  to  be  used  to 
train.  This  narrative  includes  where  the  device  is  to  be  used 
(institution,  unit,  local  training  area,  home  station),  who  will  use  it 
(individuals,  crews,  reserve  and/or  active  components),  and  how 
the  device  fits  into  the  overall  hierarchy  of  training  prerequisite 
skills  and  knowledge. 

The  training  developer  must  ensure  that  ail  information  critical  to  the 
successful  employment  to  standards  of  the  proposed  device  is  covered 
in  this  annex  and  that  this  information  is  an  integral  element  in  the 
prevailing  CATS. 


Requirements  for  commercially  available  (off-the-shelf)  devices  meeting 
the  criteria  of  an  NDI  are  documented  using  the  ORD.  This  action  is 
based  on  an  approved  MNS  as  with  any  other  nonsystem  device. 
However,  since  this  solution  to  a  training  need  minimizes  or  eliminates 
developmental  risk,  ORD  annexes  and  supporting  documentation  will  be 
tailored  accordingly. 


Other  supporting  documents  and  data  that  are  required  in  conjunction 
with  the  ORD  are  discussed  in  detail  in  chapter  5. 


AR  70-1 ,  Army  Acquisition  Policy 

AR  350-38,  Training  Device  Policies  and  Management 

TRADOC/AMC  Pam,  70-1 1 ,  RAM  Rationale  Report  Handbook 
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CHAPTER  4 

SYSTEM  TRAINING  DEVICE 
REQUIREMENTS  DOCUMENTATION 


System  Training  Device  Requirements  Documentation 

Overview 


Introduction 


Documenting  the 
Requirement 


Comment 


U.S.  Army  policy  dictates  the  fielding  of  total  syctems.  The  term  "total 
system"  refers  to  a  materiel  system  that  when  fielded  is  complete  with 
all  training  and  support  subsystems.  It  is  the  responsibility  of  the 
proponent  training  developer  to  ensure  that  the  training  subsystem  is 
identified,  developed,  procured,  and  fielded  with  the  system  it  will 
support.  To  this  end,  the  training  developer  must  be  cognizant  of  the 
documentation  requirements  for  the  proposed  system,  the  training  input 
to  this  documentation,  and  the  supporting  documentation  prepared  by 
the  training  developer. 

This  chapter  provides  pertinent  information  on  the  system  requirements 
documentation.  Although  system  requirements  documentation  is  the 
responsibility  of  the  proponent  combat  developer  supported  by  the 
materiel  developer,  the  training  developer  has  specific  responsibilities  to 
provide  training-related  input  to  the  documentation  and  to  author  much 
of  the  supporting  documentation.  This  required  input  is  addressed  in 
detail  in  this  chapter.  Supporting  documentation  is  presented  in  detail  in 
chapter  5. 


There  are  two  primary  documents  that  are  essential  to  the  development 
and  acquisition  of  new  materiel  systems: 

•  Mission  need  statement  (MNS). 

•  Operational  requirements  document  (ORD). 


Although  detailed  information  regarding  supporting  documentation  is  not 
presented  in  this  chapter,  training  developers  should  be  cognizant  of  the 
fact  that  requirements  documentation  will  not  be  approved  without  these 
supporting  documents.  More  to  the  point,  the  training  subsystem, 
including  system  TADSS,  may  lag  behind  in  funding  and/or  development 
if  not  identified  and  documented  early  in  the  system  acquisition  process. 
Close  coordination  with  the  proponent  combat  developer  must  be 
maintained  throughout  the  process,  and  all  documentation  must  be 
completed  at  appropriate  points  in  the  process  before  device 
development  and  acquisition  can  begin  or  proceed. 
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Mission  Need 
Statement  (MNS) 


Operational 
Requirements 
Document  (ORD) 


Supporting 

Documentation 


The  MNS  is  the  initiating  document  for  any  materiel  acquisition  program. 
The  proponent  combat  developer  prepares  the  MNS  with  input  from  the 
training  developer  and  materiel  developer.  The  MNS  does  not  propose 
a  materiel  solution  to  the  stated  need  but  rather  addresses  a 
requirement  as  a  mission  need.  HQDA  approval  of  the  MNS  constitutes 
a  milestone  0  decision  and  permits  the  conduct  of  conceptual  studies  to 
determine  alternative  solutions  to  meet  the  stated  need. 


The  ORD  describes  the  operational  parameters  for  a  proposed  materiel 
system.  The  combat  developer  prepares  the  ORD  with  input  from  the 
training  developer  and  materiel  developer  and  many  other  players  in  the 
materiel  acquisition  process  (logisticians,  testers,  users).  ORD 
development  is  an  iterative  process  requiring  close  and  constant 
coordination  throughout  the  process.  When  approved,  the  system 
acquisition  program  may  proceed  to  a  milestone  I  (or  I/ll  or  l/lll)  decision 
permitting  continuation  of  the  acquisition  program.  Major  training 
developer  Input  to  ORD  development  lies  in  preparation  of  the  training 
support  requirements  (TSR)  annex,  which  details  requirements  for 
training  programs  and  system  TADSS. 


Supporting  documentation  required  for  approval  of  system  requirements 
documentation  will  be  mentioned  throughout  this  chapter.  The  level  of 
detail  for  these  documents  varies  depending  on  the  complexity,  cost,  or 
basis  of  issue  of  the  proposed  training  products  and  materiel  to  support 
the  system.  The  following  are  some  of  the  primary  supporting 
documents  associated  with  the  development  and  acquisition  of  systems: 

ORD  annexes 

•  Annex  A,  Rationale. 

•  Annex  B,  Coordination. 

•  Annex  C,  Training  Support  Requirements  (TSR). 

Other  supporting  documentation 

•  System  MANPRINT  management  plan  (SMMP). 

•  Test  and  evaluation  master  plan  (TEMP). 
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Documentation 
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Pertinent 
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and  Publications 
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•  Basis  of  issue  plan  (BOIP)/qualitative  and  quantitative  personnel 
requirements  information  (QQPRI). 

•  System  training  plan  (STRAP). 

•  Distribution  plan. 

•  Reliability,  availability  and  maintainability  (RAM)  rationale  report. 

•  Training  effectiveness  analysis  (TEA). 

Additional  information  on  this  supporting  documentation  can  be  found  in 
chapter  5. 


DODI  5000.2,  Defense  Acquisition  Management  Policies  and 
Procedures 

DOD  5000.2-M,  Defense  Acquisition  Management  Documentation  and 
Reports 

AR  70-1 ,  Army  Acquisition  Policy 

AR  350-38,  Training  Device  Policies  and  Management 


System  Mission  Need  Statement,  pg.  4-4 
System  Operational  Requirements  Document,  pg.  4-9 
Annex  C,  Training  Support  Requirements,  pg.  4-20 
Training  Device  Requirements  Data  Package,  pg.  4-26 
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System  Mission  Need  Statement 


Introduction 


Purpose 


Comment 


When  a  need  for  a  materiel  system  has  ueen  identified  as  the  solution 
to  a  deficiency,  it  must  directly  relate  to  a  specified  mission  need.  This 
correlation  is  accomplished  by  the  development  of  a  MNS.  The  MNS  is 
the  initiating  document  that  is  a  prerequisite  for  acquisition  of  all  materiel 
systems.  It  is  a  general  statement  that  expresses  the  need  in  terms  of 
the  required  operational  capability  of  the  proposed  system.  The 
proponent  combat  developer  develops  the  system  MNS  with  input  from 
the  training  developer  and  materiel  developer. 


The  MNS  has  three  main  purposes: 

•  Define  the  battlefield  deficiency  in  terms  of  operational  need  to 
provide  multiple  options  for  analysis. 

•  Document  a  mission  need  that  cannot  be  satisfied  by  a 
nonmateriel  solution. 

•  Obtain  a  milestone  0  decision  to  authorize  conceptual  studies  to 
be  conducted  in  the  Concept  Exploration  and  Definition  phase 
(phase  0)  of  the  materiel  acquisition  program. 


Although  the  is  not  a  stated  purpose  of  the  MNS,  the  training  developer 
should  look  upon  this  document  as  the  first  opportunity  to  begin  the 
training  and  TADSS  requirements  identification  process  for  a  proposed 
new  materiel  system.  The  inclusion  in  this  document  of  broad  training 
requirements,  in  the  form  of  constraints  on  the  system,  will  facilitate 
further  training  subsystem  requirements  documentation. 
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Process 


Development  of  the  system  MNS  begins  with  the  identification  of  a 
mission  need(s)  or  deficiency(ies)  through  the  continuing  assessment  of 
current  and  projected  capabilities.  These  deficiencies  are  described  in 
terms  of  operational  capability  needs  and  evaluated  to  determine  if  they 
can  be  satisfied  by  nonmateriel  solutions  such  as  changes  in  doctrine, 
tactics,  training,  or  organization.  If  an  identified  need  cannot  be  satisfied 
by  a  nonmateriel  solution,  a  MNS  is  prepared  using  the  format  outlined 
in  DOD  Manual  5000. 2- M,  Defense  Acquisition  Management 
Documentation  and  Reports.  The  training  developer  becomes  involved 
in  this  process  when  the  manpower  and  personnel  integration 
(MANPRINT)  joint  working  group  (JWG)  is  convened  to  initiate  the  draft 
System  MANPRINT  Management  Plan  (SMMP)  and  to  determine  if  a 
formal  Early  Comparability  Analysis  (ECA)  should  be  conducted. 

Combat  developers  and  training  developers  use  the  information  gained 
from  the  ECA  to  assist  in  developing  input  to  the  system  MNS.  If  a 
formal  ECA  is  not  conducted,  the  training  developer  should  use  the 
thought  process  behind  the  ECA  to  determine  broad  training  strategies 
and  identify  the  kinds  of  TADSS  that  may  be  required.  Detailed 
information  regarding  conduct  of  an  ECA  can  be  found  in  the  Training 
Developers’  Procedural  Guide  for  Identifying  Requirements  for  System 
Devices. 

Through  the  ECA  process  the  training  developer  will  have  determined 
the  probable  requirement  for  system  TADSS  to  support  the  initial 
training  strategy.  These  requirements  are  documented  in  paragraph  5 
of  the  MNS  so  that  they  may  be  further  evaluated  during  concept 
studies  in  phase  0  of  the  acquisition  program. 

The  proponent  combat  developer  staffs  the  MNS  with  other  TRADOC 
schools  as  appropriate  and  forwards  it  through  the  integrating  command 
to  HQ  TRADOC  for  further  staffing  as  required  and  submission  to  HQDA 
for  approval.  HQDA  is  the  lowest  approval  authority  for  a  MNS.  A 
graphic  depiction  of  the  MNS  development/approval  process  is  shown 
below. 
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Conte  nt/Format 


Paragraph  1 
Dafanaa  Planning 
Quldanca 


Paragraph  2 
Mission  and  Thraat 
Analyses 


Paragraph  3 
Nonmaterial 
Alternatives 


The  system  MNS  consists  of  five  paragraphs  and  is  not  to  exceed  five 
pages  in  length.  Additional  information  to  help  explain  or  define  the 
need  may  be  appended  to  the  basic  document. 


MISSION  NEED  STATEMENT  (MNS) 

1.  Defense  Planning  Guidance  Element 

2.  Mission  and  Threat  Analysis 

3.  Nonmateriel  Alternatives 

4.  Potential  Materiel  Alternatives 

5.  Constraints 


The  combat  developer  identifies  the  major  program  planning  objective  or 
section  of  file  Defense  Planning  Guidance  to  which  the  stated  need 
responds.  Reference  to  DOD  or  long-range  investment  plans,  if 
applicable,  is  also  provided.  Also  included  are  needs  related  to  the 
Army  modernization  plan  (AMP). 


The  combat  developer  identifies  and  describes  the  mission  need  or 
deficiency.  The  need  is  defined  in  terms  of  mission,  objectives,  and 
general  capabilities.  The  need  is  not  presented  in  terms  of  equipment 
or  system-specific  performance  characteristics.  The  validated  threat  to 
be  countered  and  the  projected  threat  environment  and  shortfalls  of 
existing  capabilities  or  systems  in  meeting  these  threats  are  described. 
The  timing  of  the  need  and  its  general  priority  relative  to  others  in  this 
functional  area  are  also  discussed. 


The  combat  developer  discusses  the  results  of  the  mission  area 
analysis.  This  paragraph  should  identify  any  changes  in  U.S.  or  allied 
doctrine,  operational  concepts,  tactics,  organization,  and  training  that 
were  considered  in  the  context  of  satisfying  the  deficiency.  An 
explanation  as  to  why  such  changes  were  judged  to  be  inappropriate 
and/or  inadequate  must  be  provided. 
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Paragraph  4 
Potential  Materiel 
Alternatives 


Paragraph  5 
Constraints 


The  combat  developer  identifies  any  known  systems  or  programs  that 
address  similar  needs  that  are  in  use,  under  development,  or  in 
production  by  other  services  or  allied  nations.  The  potential  for 
interservice  or  allied  cooperation  is  discussed.  Potential  areas  of  study 
for  concept  exploration/definition  including  the  use  of  existing  U.S.  or 
allied  military  commercial  systems  and/or  product  improvements  of 
existing  systems  are  also  indicated.  These  alternatives  are  not 
evaluated  in  the  MNS. 


The  combat  developer  describes,  as  applicable,  key  conditions  and 
parameters  related  to  infrastructure  support  that  may  impact  on 
satisfying  the  mission  need.  Considerations  include  but  are  not  limited 
to  the  following  areas: 

•  Logistics  support. 

•  Transportation. 

•  Mapping,  charting,  and  geodesy  support. 

•  MANPRINT  (including  training  and  TADSS). 

•  Command,  control,  communications,  and  intelligence  (C3I). 

•  Security. 

•  Standardization  or  interoperability  with  NATO,  other  allies,  and 

other  DOD  components. 

•  The  level  of  desired  mission  capabilities  in  these  operational 
environments: 

Conventional  and  nuclear  weapons  effects. 

Nuclear,  biological,  and  chemical  contamination  (NBCC) 
impact. 


Electronic  and  natural  limitations. 

Subparagraphs  are  used  as  necessary  to  provide  for  complete 
discussion  of  this  information. 
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Training  Developer 
Input 


Pertinent 
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Publications 


Related  Pages 


The  training  developer's  main  responsibility  in  the  system  MNS 
development  is  to  ensure  that  prescribed  information  on  training  support 
requirements,  to  include  training  devices  and  embedded  training,  is 
documented  in  Paragraph  5,  Constraints.  The  basic  concept  for  training 
the  proposed  system  should  have  been  determined  through  the  ECA 
process. 


DOD  Manual  5000.2M,  Defense  Acquisition  Management 
Documentation  and  Reports 

AR  602-2,  Manpower  and  Personnel  Integration  (MANPRINT)  in  the 
Materiel  Acquisition  Process 


System  Operational  Requirements  Document,  pg.  4-9 
System  Training  Plan,  pg.  5-5 
Training  Effectiveness  Analysis  Process,  pg.  6-8 
Other  Joint  Working  Groups,  pg.  7-13 
Combined  Arms  Training  Strategy,  pg.  8-5 
Modification  Management,  pg.  9-1 
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System  Operational  Requirements  Document 


Introduction 


Purpose 


When  i+  is  determined  that  the  solution  to  a  deficiency  is  a  new  materiel 
system,  and  a  MNS  has  been  approved,  the  proponent  combat 
developer  prepares  the  ORD.  The  system  ORD  is  a  formal 
requirements  document  that,  when  approved  and  funded,  permits  a 
program  to  proceed  to  a  milestone  I  decision  thereby  allowing 
development  or  production,  The  ORD  concisely  states  the  minimum 
essential  operational,  technical,  logistic,  training  support,  and  cost 
parameters  necessary  to  initiate  development  or  procurement  of  a 
system. 

The  combat  developer  prepares  the  system  ORD;  however,  the  training 
developer  coordinates  and  provides  input  on  training,  training  support, 
and  TADSS  requirements.  Training  developer  coordination  with  the 
combat  developer  must  be  proactive  and  routine.  Maintaining  close 
relationships  with  the  combat  development  studies  personnel  and 
possessing  full  knowledge  of  the  emerging  operational  concept  provide 
the  opportunity  to  ensure  appropriate  system-  and  training-based 
solutions  are  applied  to  the  stated  battlefield  deficiency. 

Training  developers  must  attend  the  combat  development  work  groups 
to  discuss  training  constraints  and  problems  associated  with  the 
proposed  system.  During  the  drafting  of  the  ORD  and  after  its  approval, 
proactive  training  developer  input  to  the  SMMP  and  solutions  to 
MANPRINT  issues  will  ensure  that  training  support  and  training  device 
areas  of  interest/influence  are  properly  addressed  in  the  system's 
requirement  documents. 


The  system  ORD  has  four  main  purposes: 

•  Provide  decision  makers  with  the  minimum  essential  information 
necessary  to  complete  the  Concept  Exploration  and  Definition 
phase  and  proceed  to  the  Demonstration  and  Validation/ 
Engineering  and  Manufacturing  Development  phases  of  the 
acquisition  process. 

•  Provide  the  materiel  developer  with  the  information  essential  to 
the  preparation  of  a  request  for  proposal  (RFP)  to  industry  for 
system  development. 
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Purpose  (con.) 


Process 


Describe  the  system's  minimum  essential  operational  and 
support  characteristics. 

Define  the  system's  training  support  package  including 
embedded  training  and  training  device  requirements. 


After  the  system  MNS  has  been  approved,  the  combat  developer  begins 
development  of  the  ORD.  The  proponent  combat  developer  prepares 
the  system  ORD  with  input  from  the  materiel  developer,  training 
developer,  logistician,  MANPRINT  domain  personnel,  test  and  evaluation 
elements,  and  interested  MACOMs.  The  following  areas  are  addressed 
in  the  ORD: 

•  Operational  characteristics  of  the  system  and  embedded  training 
requirements. 

•  A  technical  assessment  and  associated  risks. 

•  A  system  support  assessment  including  a  statement  and 
information  on  the  system  support  plan  testing  during  Initial 
Operational  Test  and  Evaluation  (IOT&E). 

•  MANPRINT  requirements,  including-- 

Manpower/force  structure  assessment. 

Personnel  assessment. 

Training  assessment  including  the  need  for  TADSS. 
Human  factors  engineering  (HFE)  assessment. 

System  safety  assessment. 

Health  hazard  assessment. 

•  Standardization  and  interoperability. 

•  Milestone  schedule. 

The  development  of  the  system  ORD  is  a  progressive  action.  The 
process  is  graphically  depicted  in  the  next  figure.  Additional  information 
Is  gained  from  system  studies  related  to  operational  and  training 
requirements.  This  data  is  integrated  as  appropriate. 


4-10 


Process  (con.) 


When  the  combat  developer  at  the  proponent  school  completes  the 
system  ORD  draft,  it  is  staffed  internally  and  externally  to  all 
interested/affected  agencies.  The  training  developer  continues  to 
update  the  system  training  plan  (STRAP)  with  emerging  information  from 
the  ECA,  the  HARDMAN  analysis  (if  conducted),  and  other  system 
studies.  Upon  completion  of  staffing  and  receipt  of  input  to  the  system 
ORD,  a  JWG  is  convened  to  finalize  the  system  ORD  for  the  approval 
process. 


STRAP 


Approved 

MNS 


Draft 

ORD 

Combat 

Developer 


System  COEA 


System  TEA 
- 1 - 


Complete  ORD 
Package  (Combat 
Developer) 


ECA 


HARDMAN 


MANPRINT  ACTIVITIES 


Because  detailed  information  regarding  training  device  characteristics  is 
not  normally  available  at  the  time  of  system  ORD  development  and 
approval,  the  training  developer  provides  as  much  data  as  possible  and 
continues  to  research  device  designs  and  strategies.  A  training  device 
concept  formulation  is  developed  as  soon  as  the  system  studies  provide 
sufficient  information  to  analyze  device  technologies. 

At  this  point  in  the  process,  the  training  developer  obtains  training- 
related  information  from  logistical  support  analysis  (LSA)  data  and  the 
results  of  any  operational  testing  of  the  system  and  system  support 
package.  Final  training  device  requirements  and  characteristics  are  then 
developed  and  submitted  in  the  training  device  requirements  data 
package. 
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Content/Format 


Paragraph  1 
General  Description 
of  Operational 
Capability 


The  ORD  consists  of  eight  paragraphs  with  subparagraphs  as  applicable 
to  fully  define  the  requirement  A  completed  OR D  package  will  also 
contain  three  annexes.  The  content  and  format  for  the  ORD  can  be 
found  in  DOD  5000.2M,  Defense  Acquisition  Management 
Documentation  and  Reports. 


OPERATIONAL  REQUIREMENTS  DOCUMENT  (ORD) 

1.  General  Description  of  Operational  Capability 

2.  Threat 

3.  Shortcomings  of  Exisitng  Systems 

4.  Capabilities  Required 

5.  Integrated  Logisitic  Support  (ILS) 

6.  Infrastructure  Support  and  interoperability 

7.  Force  Structure 

8.  Schedule  Considerations 


RATIONALE 


Annex  A 


COORDINATION 


Annex  B 


TRAINING  SUPPORT  REQUIREMENTS  Annex  C 


Paragraph  1  contains  information  describing  the  overall  mission  area, 
type  of  system  proposed,  and  the  anticipated  operational  and  support 
concepts  in  sufficient  detail  to  support  program  and  logistics  support 
planning.  It  contains  a  brief  summary  of  the  MNS.  If  a  MNS  did  not 
precede  foe  ORD,  the  process  that  examined  alternatives  to  satisfy  the 
mission  need  and  development  of  the  operational  requirements  is 
explained. 
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Paragraph  2 
Threat 


Paragraph  3 
Shortcomings  of 
Existing  Systems 


Paragraph  4 
Capabilities 
Required 


This  paragraph  summarizes  the  threat  and  the  projected  environment. 
Threat  information  should  reference  Defense  Intelligence  Agency  (DIA) 
or  Service  Technical  Intelligence  Center  approved  documents  and 
should  be  validated  by  the  Service  Intelligence  Director.  For  major 
defense  acquisition  programs,  the  DIA-validated  System  Threat 
Assessment  Report  is  referenced.  In  some  nonwar-fighting  systems,  the 
threat  may  be  listed  as  "not  applicable." 


This  paragraph  explains  why  existing  systems  do  not  meet  current  or 
projected  requirements.  Proposed  systems  are  not  described  in  this 
paragraph. 


In  this  paragraph  the  combat  developer  identifies  performance  data 
(operational  effectiveness  and  suitability)  capabilities  and  characteristics 
required.  These  are  stated  in  operational  terms  and  priorities  if  possible. 
Performance  parameters  are  specified  in  terms  of  a  minimum 
acceptable  value  (threshold)  required  to  satisfy  the  mission  need  and 
objective.  The  objective  should  represent  a  measurable,  beneficial 
increase  in  capability  or  operations  and  support  capabilities  above  the 
identified  threshold. 

Subparagraphs  to  the  Capabilities  Required  paragraph  of  the  ORD  are 
tailored  to  include  and/or  describe,  as  applicable,  system  performance 
parameters  or  considerations  in  the  following  major  and  subtopical 
areas: 

4a.  System  Performance  -  includes  system  performance  parameters 
such  as  range,  accuracy,  payload,  speed,  and  mission  reliability. 
Mission  scenarios  (wartime  and  peacetime  if  different)  are 
described  in  terms  of  mission  profiles,  employment  tactics,  and 
environmental  factors  (all-inclusive,  natural,  and  man-made,  for 
example,  weather,  countermeasures,  ocean  acoustics.) 

4b.  Logistics  and  Readiness  -  includes  measures  for  mission-capable 
rate,  operational  availability,  frequency  and  duration  of  preventive 
or  scheduled  maintenance  actions,  etc.  Measures  are  described 
in  terms  of  mission  requirements  considering  both  wartime  and 
peacetime  logistics  operations.  Combat  support  requirements 
are  identified  including  battle  damage  repair  capability,  mobility 
requirements,  expected  maintenance  manpower  and  skill  levels, 
and  surge  and  mobilization  objectives  and  capabilities. 
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Paragraph  4 
Capabilities 
Required  (con.) 


Paragraph  5 
Integrated  Logistics 
Support  (ILS) 


4c.  Critical  System  Characteristics  -  addresses  electronic  counter 
countermeasures  (ECCM)  and  wartime  reserve  modes  (WARM) 
requirements,  conventional  and  initial  nuclear  weapons  effects, 
nuclear,  biological,  and  chemical  (NBC)  contamination 
survivability,  natural  environmental  factors  (such  as  climate  and 
terrain  factors),  and  electromagnetic  compatibility  and  frequency 
spectrum  assignment  of  systems  operating  in  the 
electromagnetic  spectrum.  The  expected  mission  capability  is 
defined  (full,  percent  degraded,  etc.)  in  the  various  environments. 
Applicable  safety  parameters  such  as  those  related  to  system, 
nuclear,  explosive,  and  flight  safety  are  included. 
Communications,  information,  and  physical  and  operational 
security  needs  are  identified. 

Note:  While  the  training  concept  in  paragraph  5-C  includes  any 

embedded  training  requirements,  these  requirements  must  also 
be  identified  in  the  appropriate  subparagraph  of  paragraph  4. 
This  ensures  that  all  required  embedded  training  capabilities  are 
identified  and  that  the  appropriate  corresponding  rationale  is 
annotated  in  the  rationale  annex. 


In  paragraph  5,  along  with  its  subparagraphs,  the  organizational, 
intermediate,  and  depot-level  support  objectives  for  initial  operational 
capability  (IOC)  and  full  operational  capability  (FOC)  are  established. 

5a.  Maintenance  Planning  -  identifies  maintenance  tasks  to  be 

accomplished  and  time  phasing  for  depot  maintenance  including 
programmed  depot  maintenance  and  surveillance  inspections 
such  as  nuclear  hardness  and  structural  integrity.  The  planning 
approach  for  contract  versus  organic  repair  is  also  described. 

5b.  Support  Equipment  -  defines  the  standard  support  equipment  to 
be  used  by  the  system.  The  test  and  fault  isolation  capabilities 
desired  of  the  automatic  test  equipment  at  all  levels  are 
expressed  in  terms  of  realistic  and  affordable  probabilities  and 
confidence  levels. 
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Paragraph  5 
Integrated  Logistics 
Support  OLS)  (con.) 


5c.  Human  Systems  Integration  -  briefly  describes  the  operational 
and  maintenance  training  concept  (pipeline,  training  devices, 
embedded  training/on-board  training,  interactive  courseware). 
Manpower,  personnel,  training,  human  factors  engineering, 
system  safety,  and  health  hazard  constraints  are  identified. 
Objectives  and  thresholds  are  established  if  applicable  for 
manpower  (force  structure  and  end  strength),  personnel 
(numerical  and  skill  level),  training,  and  safety.  Manpower  and 
training  methodologies  to  be  used  are  specified  (for  example, 
HARDMAN  comparability  methodology). 

Note:  Training  developers  must  provide  requirements  for  embedded 

training  and  TADSS  to  the  combat  developer  for  input  to  this  paragraph. 

Details  on  these  requirements  will  be  documented  in  Annex  E,  Training 

Support  Requirements. 

5d.  Computer  Resources  -  identifies  computer  resource  constraints 
(language,  computer,  data  base,  architecture,  or  interoperability 
constraints).  All  mission-critical  and  supporting  computer 
resources  are  addressed  including  automated  test  equipment. 
The  capabilities  desired  for  integrated  computer  resources 
support  are  described.  Explanations  of  unique  user  interface 
requirements,  documentation  needs,  and  special  software 
certifications  are  provided. 

5e.  Other  Logistics  Considerations  -  describes  the  provisioning 
strategy  for  the  system.  Any  unique  facility  and  shelter 
requirements  are  specified.  Special  packaging,  handling,  and 
transportation  considerations  are  identified.  Unique  data 
requirements  are  defined,  such  as  engineering  data  for  depot 
support  and  technical  orders  for  the  system  and  depot. 


Paragraph  6 
Infrastructure 
Support  and 
Interoperability 


In  this  paragraph  the  combat  developer  discusses  interfacing  systems 
(at  the  system/subsystem,  platform,  and  force  levels),  specifically  those 
related  to  C3I,  transportation,  basing,  and  standardization  and 
interoperability.  Related  ORD  and  other  services  that  may  have  similar 
requirements  are  identified.  A  joint  potential  designation  is  assigned 
(joint,  joint  interest,  or  independent). 
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Paragraph  6 
Infrastructure 
Support  and 
Interoperability 
(con.) 


Paragraph  7 
Force  Structure 


6a.  Command,  Control,  Communications,  and  Intelligence  - 
describes  how  the  system  will  be  integrated  into  the  C3I 
architecture  anticipated  to  exist  at  the  time  the  system  will  be 
fielded.  Included  are  data  requirements  (data,  voice,  video), 
computer  network  support,  and  antijamming  requirements. 

Unique  intelligence  information  requirements  including 
intelligence  interfaces,  communications,  and  data  base  support 
pertaining  to  target  and  mission  planning  activities,  threat  data, 
etc.  are  included. 

6b.  Transportation  and  Basing  -  describes  how  the  system  will  be 
moved  to  or  within  the  theater  and  identifies  any  lift  constraints. 
The  basing  and  associated  facilities  available  for  training 
locations  and  main  and  forward  operation  bases  are  provided. 

6c.  Standardization,  Interoperability,  and  Commonality  -  describes 

considerations  for  joint  use,  National  Atlantic  Treaty  Organization 
(NATO)  cross-servicing,  etc.  Procedural  and  technical  interfaces 
and  communications,  protocols,  and  standards  required  to  be 
incorporated  to  ensure  interoperability  with  other  services,  joint 
service,  and  allied  systems  are  identified.  Energy 
standardization  and  efficiency  needs  for  fuel  and  electrical  power 
are  addressed  as  applicable. 

6d.  Mapping,  Charting,  and  Geodesy  Support  -  identifies 

cartographic  materials,  digital  topographic  data,  and  geodetic 
data  needed  for  system  employment.  Where  possible,  Defense 
Mapping  Agency  standard  military  data  will  be  used. 

6e.  Environmental  Support  -  identifies  the  standard  and  unique 

weather,  oceanographic,  and  astrogeophysical  support  required. 
Data  accuracy  and  forecast  frequency  requirements  are  included. 


This  paragraph  contains  the  estimated  number  of  systems  or 
subsystems  needed  including  spares  and  training  units.  The  platforms 
and  quantities  including  other  services  or  government  agencies,  if 
appropriate,  that  will  employ  the  systems  or  subsystems  being 
developed  and  procured  to  satisfy  this  ORD  are  identified. 

Note:  Training  developers  must  provide  the  combat  developer  with 
estimates  of  systems  or  components  required  for  training  and  estimates 
of  the  number  of  TADSS. 
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Paragraph  8 

Schedule 

Considerations 


Annex  A 
Rationale 


Annex  B 
Coordination 


Annex  C 
Training  Support 
Requirements  (TSR) 


Paragraph  8  defines  what  actions,  when  complete,  will  constitute 
attainment  of  IOC  and  FOC  (remains  flexible  for  revision  as  the  program 
is  progressively  defined  and  trade-off  studies  are  completed).  The 
operational  capability  or  level  of  performance  necessary  to  declare  IOC 
and  FOC  is  defined.  The  numbers  of  operational  systems,  operational 
and  support  personnel,  facilities,  and  organizational,  intermediate,  and 
depot  support  elements  that  must  be  in  place  are  included.  If  availability 
in  a  specific  time  frame  is  important,  an  objective  for  IOC  is  specified. 
The  impact  if  this  objective  is  not  achieved  is  described,  and  a  window 
of  acceptability  is  identified  if  appropriate. 


Annex  A  contains  the  rationale  for  each  of  the  essential  characteristics 
that  were  developed  for  the  system  and  documented  in  paragraph  4 
(Capabilities  Required)  of  the  basic  document.  Each  essential 
characteristic  that  is  identified  for  the  system  must  have  a  corresponding 
rationale.  Characteristics  without  an  acceptable  rationale  will  not  be 
accepted.  Annex  A  will  also  include  a  synopsis  of  the  executive 
summary  of  the  approved  RAM  Rational  Report  (RRR). 


Annex  B  is  used  to  document  all  comments  that  were  received  during 
staffing  of  the  ORD  that  were  not  accepted  for  inclusion  into  the 
document.  Each  comment  that  is  not  accepted  must  have  a 
corresponding  justification  for  its  nonacceptance. 


Annex  C  provides  a  comprehensive  description  of  all  training  support 
requirements  including  embedded  training  capabilities  and  TADSS.  This 
chapter  contains  detailed  information  on  the  content  and  format  of 
annex  C  beginning  on  page  4-20. 
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Training  Developer 
Input 


Pertinent 
Regulations  and 
Publications 


Related  Pages 


Because  the  system  ORD  establishes  funding  parameters  and  provides 
the  definition  of  the  requirements  from  which  the  materiel  developer  will 
prepare  an  RFP  to  industry,  it  is  essential  that  the  training  developer 
identifies  and  documents  to  the  maximum  extent  possible  ail  training 
support  requirements  and  costs.  This  is  accomplished  by  working 
routinely  and  proactively  with  the  combat  developer  and  materiel 
developer  throughout  *he  system  ORD  development  process  to  ensure 
that  all  training  considerations  are  addressed  in  the  ORD.  Extraordinary 
attention  should  be  focused  on  the  training  support  requirements 
detailed  in  Annex  C,  TSR. 


DOD  Manual  5000.2M,  Defense  Acquisition  Management 
Documentation  and  Reports 

AR  602-2,  Manpower  and  Personnel  Integration  (MANPRINT)  in  the 
Materiel  Acquisition  Process 

TRADOC  Reg  351-9,  Systems  Training  Development 


System  Mission  Need  Statement,  pg.  4-4 

Annex  C,  Training  Support  Requirements,  pg.  4-20 

System  Training  Plan,  pg.  5-5 

Reliability,  Availability,  and  Maintainability,  pg.  5-17 

System  MANPRINT  Management  Plan,  pg.  5-23 

Training  Effectiveness  Analysis  Process,  pg.  6-8 

Concept  Formulation,  pg.  6-12 

Training  Device  Joint  Working  Group  Process,  pg.  7-3 

Other  Joint  Working  Groups,  pg.  7-13 

Combined  Arms  Training  Strategy,  pg.  8-5 
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Related  Pages 

(con.) 


Requirements  Review  Committee,  pg.  8-8 
Training  Device  Requirements  Review  Committee,  pg.  8-11 
In-Process  Review,  pg.  8-14 
Modification  Management,  pg.  9-1 
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Annex  C,  Training  Support  Requirements 


Introduction 


Purpose 


Comment 


The  TSR  Annex  to  the  system  ORD  provides  a  detailed  summary  of  all 
training  support  requirements  tor  the  developing  system.  A  well 
documented  TSR  annex  will  provide  the  system  acquisition  program 
management  with  the  information  necessary  to  program  funding  and 
developmental  actions  to  ensure  that  the  training  subsystem  can  be 
developed,  tested,  and  procured  along  with  the  system  it  supports. 


The  TSR  annex  has  five  main  purposes: 

•  Inform  the  combat  developer  and  materiel  developer  of  the 
system  training  support  requirements  including  embedded 
training  capabilities  and  TADSS. 

•  Identify  funding  requirements  to  support  development  and 
procurement  of  system  TADSS. 

•  Facilitate  the  development  of  training  plans  based  on  the  training 
subsystem. 

•  Provide  information  for  facilities  and  logistic  support 
requirements. 

•  Allow  tracking  of  the  proposed  training  support  items  through  the 
materiel  acquisition  process  in  concert  with  system  development. 


The  TSR  annex  is  developed  concurrently  with  the  system  ORD  and 
attached  to  the  basic  document  as  annex  C.  While  the  ORD  provides 
essential  information  for  the  system  to  proceed  to  a  milestone  I/ll 
decision  and  an  RFP,  the  annex  will  normally  not  provide  sufficient 
information  for  a  training  device  statement  of  work  (SOW)  for  an  RFP 
and  developmental  actions.  At  this  point,  sufficient  system  LSA  data 
has  not  yet  been  generated  to  support  training  device  concept 
formulation.  When  the  training  developer  has  analyzed  LSA  data  and 
training  device  concept  formulation  has  been  completed,  the  device  can 
be  developed,  either  by  the  prime  (system  contractor)  or  under  a 
separate  contract. 
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Process 


Comment 


The  training  developer  has  been  formulating  the  training  concept  since 
the  ECA  and  initial  input  to  the  system  MNS.  This  training  concept  and 
support  requirements  to  accomplish  training  under  the  concept  have 
been  documented  in  the  STRAP  (see  chapter  5).  If  the  training 
developer  has  prepared  a  detailed  STRAP,  development  of  the  TSR 
annex  will  not  present  a  major  effort.  All  information  required  to  prepare 
this  annex  is  derived  from  the  STRAP,  which  results  from  the  following: 

•  The  ECA. 

•  Training  constraints  in  the  MNS. 

•  Required  system  embedded  training  capability (ies). 

•  Information  gained  from  actions  and  analyses  conducted  under 

the  SMMP. 

•  System  cost  and  operational  analysis  (COEA)  and  training 
effectiveness  analysis  (TEA). 

•  The  proposed  basis  of  issue  for  the  system. 


It  is  important  to  remember  that  the  STRAP  and  the  SMMP  are  evolving 
documents  that  are  updated  and  modified  throughout  the  acquisition 
cycle.  As  such,  the  data  that  is  being  developed  for  the  TSR  annex  is 
continually  affected  and  requires  routine  review  and  update. 
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Conte  nt/Format 


The  TSR  annex  summarizes  the  training  support  requirements  that  have 
been  identified  through  analyses  and  documented  in  the  STRAP.  It 
provides  the  materiel  developer  and  training  community  with  sufficient 
information  to  plan  for  development  of  the  training  devices  and  support 
items  and  eventual  fielding  and  integration  into  training  programs.  The 
annex  contains  the  following  essential  training  information: 

•  A  summary  of  system  training  constraints. 

•  The  system  training  concept  for  both  institutional  and  unit  or 
sustainment  training. 

•  A  description  of  the  embedded  training  requirements. 

•  Training  support  requirements  including  system  end  items  or 
components  for  use  in  the  training  base  and  general  support 
requirements. 

•  A  description,  in  as  much  detail  as  possible,  of  each  device 
required  for  system  training. 

The  TSR  annex  addresses  the  system  training  requirements  In  six 
general  paragraphs  and  a  separate  paragraph  lor  each  required  training 
device  beginning  with  paragraph  7. 


TRAINING  SUPPORT  REQUIREMENTS  (TSR) 
ANNEX  C  TO  SYSTEM  ORD 

1.  Training  Constraints 

2.  Training  Concept 

3.  Significant  Training  Issues  at  Risk 

4.  Embedded  Training 

5.  System  Hardware  Requirements 

6.  General  Training  Support  Requirements 

7.  Training  Device  Requirements 
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Paragraph  1 

Training 

Constraints 


Paragraph  2 
Training  Concept 


Paragraph  3 
Significant  Training 
Issues  at  Risk 


Paragraph  4 
Embedded  Training 
Requirements 


Paragraph  5 
System  Hardware 
Requirements 


This  paragraph  describes  constraints  that  impact  on  training. 
Development  of  these  constraints  helps  to  formulate  and  support  the 
rationale  for  the  training  concept.  The  SMMP  is  the  primary  source  of 
constraints  input. 


This  paragraph  explains  how  personnel  (individuals  and  crews)  are 
trained  to  operate,  maintain,  and  manage  the  system.  This  paragraph  is 
intended  to  be  an  overview  summarizing  the  detailed  training  concept  in 
the  STRAP.  Subparagraphs  cover  the  following: 

2a.  Institutional  training  strategy  -  summarizes  the  institutional 
training  strategy  as  defined  in  the  STRAP  that  includes 
considerations  applicable  to  U.S.  Army  Reserve  (USAR)  schools, 
reserve  component  training  divisions,  and  TRADOC  institutions 
as  appropriate. 

2b.  Unit  training  strategy  -  summarizes  the  unit  training  strategy  as 
defined  in  the  STRAP  that  addresses  MACOM  or  active 
component/reserve  component  (AC/RC)  unique  training 
strategies. 


This  paragraph  summarizes  the  information  contained  in  the  STRAP 
regarding  training  issues  at  risk. 


This  paragraph  states  the  functional  requirement,  if  applicable,  for  the 
system  if  it  is  to  be  designed  with  an  embedded  training  capability.  If  no 
embedded  training  requirement  exists,  the  following  statement  must  be 
made,  "The  need  for  an  embedded  training  capability  has  been 
investigated,  and  it  has  been  determined  that  no  requirement  exists.” 


This  paragraph  outlines  the  need  and  rationale  for  system  hardware  or 
components  of  the  system  to  support  the  training  base.  Subparagraphs 
are  included  that  address  each  type  of  item  and  the  projected  quantity 
required. 
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Paragraph  6 
General  Training 
Support 
Requirements 


Paragraph  7 
Training  Device 
Requirements 


This  paragraph  provides  subparagraphed  statements  of  the  need  and 
rationale  for  each  type  of  training  support  item/product  required  to 
support  training  of  the  system.  Examples  are  training-unique  munitions, 
target  systems  and  targetry,  visual  information  and  printed  products,  and 
turnkey  training.  (Training  devices  are  addressed  at  paragraph  7.) 

When  possible,  information  is  included  as  to  the  projected  quantities 
required  by  year  if  appropriate. 


This  paragraph  describes  each  training  device  requirement  in  a 
functional  statement  containing  the  type  of  device  required,  the 
environment  in  which  it  will  operate,  and  information  on  the  projected 
quantity  required.  An  example  is  “A  direct  support/general  support 
(DS/GS)  level  system  electronics  maintenance  training  device  is 
required  to  train  maintainers  in  an  institutional  environment  on  those 
skills  and  tasks  peculiar  to  this  materiel  system.  Specific  tasks  to  be 
trained  will  result  from  the  proponent’s  review  of  the  contractor-develo¬ 
ped  LSA  data.  A  total  of  nine  devices  are  required:  three  at  the 
proponent  institution,  one  at  the  Ordnance  School,  one  at  each  of  four 
regional  training  sites,  and  one  at  7ATC,  Vilseck,  Germany." 

If  more  than  one  type  of  training  device  or  simulator  is  required,  each 
will  be  addressed  in  a  separate  paragraph  sequentially  numbered  8.,  9., 
etc.  Subparagraphs  and  tabs,  as  outlined  below,  are  included  for  each 
device  and/or  simulator.  Each  training  device  paragraph  will  include  two 
subparagraphs: 

a.  Constraints  -  a  statement  or  list  of  constraints  relative  to  each  of 
the  MAN  PRINT  domains.  These  constraints  must  be  considered 
in  the  design,  operation,  and  maintenance  of  the  training  device 
or  simulator. 

b.  Logistical  support  concept  -  a  statement  of  the  proponent’s 
proposed  concept  for  logistical  support  of  the  training  device  or 
simulator,  for  example,  the  DS/GS  electronics  maintenance 
trainer  will  be  maintained  by  on-site  logistical/maintenance 
support  activities. 
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Comment 


Pertinent 
Regulations  and 
Publications 


Related  Pages 


If  the  need  for  a  system  training  device  is  determined  through  testing  or 
other  means  and  it  was  not  identified  in  the  system  ORD  and  included  in 
the  ORD  approval,  the  documentation  for  the  system  device  will  be 
prepared  using  the  NSTD  format  and  procedures  found  in  appropriate 
sections  of  this  procedural  guide.  Funding  to  support  concept 
formulation,  research  and  development,  and  procurement  remains 
programmed  and  funded  as  part  of  the  materiel  system. 


DOD  5000.2-M,  Defense  Acquisition  Management  Documentation  and 
Reports 

AR  70-1 ,  Army  Acquisition  Policy 

AR  602-2,  Manpower  and  Personnel  Integration  (MANPRiNT)  in  the 
Materiel  Acquisition  Process 

7RADOC  Reg  351-9,  System  Training  Development 


System  Operational  Requirements  Document,  pg.  4-9 
System  Training  Plan,  pg.  5-5 
Training  Effectiveness  Analysis  Process,  pg.  6-8 
Training  Device  Joint  Working  Group  Process,  pg.  7-3 
Other  Joint  Working  Groups,  pg.  7-13 
Requirements  Review  Committee,  pg.  8-8 
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Training  Device  Requirements  Data  Package 


Introduction 


Purposo 


Process 


When  the  need  for  a  STD  has  been  identified  and  documented  in  the 
TSR  annex  to  the  system  ORD,  a  concept  formulation  must  be 
performed  to  support  the  development  of  an  IPR  package  and  contract 
SOW  for  STD  development  and  procurement.  Normally,  STRICOM  will 
perform  the  concept  formulation  based  on  the  information  provided  by 
the  proponent.  This  information  constitutes  the  training  device 
requirements  data  package. 


The  purpose  of  the  data  package  is  to  provide  the  materiel  developer 
with  detailed  data  on  the  functional  requirements,  operational 
characteristics,  and  essential/critical  tasks  to  be  trained  by  the  proposed 
STD.  This  data  allows  the  materiel  developer  to  begin  the  concept 
formulation  process  leading  to  the  selection  of  the  best  technical 
approach  (BTA)  and  to  initiate  contract  actions  for  device  development 
and  procurement. 


The  training  device  requirements  data  package  is  comprised  of  key 
elements  of  information  needed  to  initiate  the  JWG  process  and  begin 
concept  formulation  for  a  proposed  training  device.  The  design  of  the 
STD  is  dependent  on  the  critical  tasks  to  be  trained  and  a  definition  of 
the  essential  operational  and  physical  characteristics.  As  the 
development  of  the  materiel  system  matures,  requirements  for  the 
training  subsystem,  including  required  STDs,  become  increasingly  clear 
and  better  defined.  The  figure  on  the  next  page  highlights  the 
development  of  the  data  package.  The  information  for  the  data  package 
is  derived  from  many  sources  and  forwarded  to  ATSC  when  all  elements 
become  available. 
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The  information  elements  comprising  the  data  package  are  obtained 
from  a  number  of  sources.  The  primary  source  of  information  is  the 
STRAP.  If  the  proponent  has  developed  a  comprehensive  STRAP  and 
updated  it  as  system  development  progresses,  then  providing  the 
information  for  the  data  package  will  not  be  a  major  effort  Other 
important  sources  of  information  include  the  TSR  annex,  task  list  derived 
from  LSA  or  other  sources,  and  system  studies  (COEA  and  TEA). 

The  proponent  compiles  the  information  elements  for  the  data  package 
and  forwards  the  completed  package  to  ATSC.  When  ATSC  and  the 
proponent  agree  that  sufficient  information  to  support  concept 
formulation  has  been  provided,  ATSC  will  forward  the  package  to 
STRICOM  and  the  JWG  membership.  Concurrently,  ATSC  will 
coordinate  a  date  and  location  for  JWG  1 .  This  then  begins  the  concept 
formulation  JWG  process  for  an  STD.  See  chapters  6  and  7 
respectively  for  the  concept  formulation  and  JWG  process. 


There  is  no  specified  format  for  a  training  device  requirements  data 
package.  It  is  simply  a  collection  of  critical  data  required  by  the  materiel 
developer  to  support  performance  of  a  concept  formulation.  As  a 
minimum,  the  following  information  is  required  to  support  the  beginning 
of  the  concept  formulation: 

•  The  system  training  strategy. 

•  Training  device  strategy. 

•  Tasks  to  be  trained  (conditions  and  standvds). 
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Target  audience  description  (military  occupational  specialty 
(MOS),  skill  level,  active/reserve). 

Proposed  training  environment  (local  training  area,  garrison, 
TRADOC  school,  combat  training  center). 

Training  constraints. 

Essential  functional  characteristics  of  the  proposed  device. 
RAM  requirements  for  the  training  device. 


Most  of  the  information  required  for  the  training  device  data  package 
can  be  found  in  the  STRAP,  in  the  results  of  system  studies,  and  in 
system  documentation  (system  ORD  with  the  TSR  annex).  Proactive 
and  frequent  participation  by  the  training  developer  in  the  development 
of  this  documentation  and  involvement  in  the  preliminary  studies  will 
simplify  the  task  of  preparing  the  data  package.  The  proponent  must  be 
involved  in  the  LSA  process  to  ensure  that  the  system  operation  and 
maintenance  tasks  information  which  is  critical  to  the  concept 
formulation  process  is  captured  and  recorded. 


TRADOC  Reg  351-9,  System  Training  Development 
AR  700-1 27,  Integrated  Logistics  Support 


Nonsystem  Training  Device  Operational  Requirements  Document, 
pg.  3-9 

System  Operational  Requirements  Document,  pg.  4-9 
Annex  C,  Training  Support  Requirements,  pg.  4-20 
System  Training  Plan,  pg.  5-5 
Concept  Formulation,  pg.  6-12 
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CHAPTER  5 

SUPPORTING  DOCUMENTATION 


Supporting  Documentation 

Overview 


Introduction 


When  a  requirement  for  a  materiel  system  and/or  training  device  has 
been  determined,  the  combat  developer  and  the  training  developer  must 
develop  the  necessary  requirements  documents.  The  primary  and 
initiating  documents  are  the  Mission  Need  Statement  (MNS)  and  the 
Operational  Requirements  Document  (ORD)  (see  chapters  3  and  4). 
Each  of  these  documents  serves  a  specific  purpose  in  the  acquisition 
process.  However,  these  documents  alone  do  not  contain  all  of  the 
required  information  to  support  development  and  procurement  actions 
under  a  materiel  acquisition  program. 

A  number  of  supporting  documents  are  essential  to  the  acquisition 
process  to  initiate  and  record  additional  information  requirements.  The 
following  are  the  major  supporting  documents  to  the  MNS  and  ORD  in 
the  development  and  acquisition  process  that  will  be  discussed  in  this 
chapter: 

•  System  training  plan  (STRAP). 

•  Basis  of  issue  plan  (BOIP)/quaiitative  and  quantitative  personnel 
requirements  information  (QQPRI). 

•  Reliability,  availability,  and  maintainability  (RAM)  data. 

•  System  MANPRINT  management  plan  (SMMP). 

•  Test  and  evaluation  master  plan  (TEMP). 

•  New  equipment  training  plan  (NETP). 

An  effectiveness  analysis  process  is  used  to  determine  cost,  operational, 
and  training  effectiveness  for  systems  and  for  training  devices.  This 
process  results  in  two  additional  supporting  documents: 

•  Cost  and  operational  effectiveness  analysis  (COEA)  -  a 
comparative  analysis  of  competing  alternatives  for  system 
design,  characteristics,  and  technology  conducted  by  the  combat 
developer.  The  COEA  is  conducted  concurrently  with  and 
supports  the  materiel  developer’s  concept  formulation  to  arrive  at 
the  best  technical  approach  (BTA)  for  system  design. 
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•  Training  effectiveness  analysis  (TEA)  -  a  generic  term  for 
comparative  analysis  of  competing  training  alternatives. 
Regarding  system  training  alternatives,  a  TEA  is  conducted 
concurrently  with  the  COEA  to  analyze  competing  system 
training  alternatives.  In  relation  to  training  devices,  TEAs  are 
conducted  to  analyze  competing  alternatives  for  device  design, 
characteristics,  and  technology  to  support  the  materiel 
developer’s  concept  formulation.  The  training  developer 
conducts  TEAs. 

Effectiveness  analyses  and  concept  formulation  are  discussed  in 
chapter  6. 

Not  all  of  these  documents  are  required  for  each  materiel  system  or 
training  device  under  development.  Within  this  chapter  each  of  these 
supporting  documents  will  be  discussed  in  the  detail  required  for  the 
training  developer.  Where  appropriate,  tailoring  of  the  process  for 
document  development  will  be  presented.  "Tailoring,"  in  this  context, 
means  that  if  complete  documentation  is  not  required  in  each  case, 
opportunities  for  exceptions  or  shortcuts  will  be  identified. 


The  STRAP  is  the  master  training  management  plan  for  a  new  system 
or  major  training  device.  It  addressees  who  is  trained  and  when,  where, 
and  how  the  training  is  conducted.  The  proponent  training  developer 
develops  the  STRAP.  Although  the  STRAP  is  required  for  each  new 
system,  it  may  not  be  required  for  all  nonsystem  training  devices 
(NSTDs). 


The  BOIP  is  a  planning  document  that  indicates  where  the  system  or 
training  device  is  to  be  located,  how  many  are  required,  and  other 
equipment  and  personnel  changes  that  will  be  required  as  a  result  of 
fielding. 

The  QQPRI  is  a  compilation  of  organizational,  doctrinal,  training,  and 
personnel  information  used  to  determine  the  need  for  a  new  or  revised 
military  occupational  specialty  (MOS)  or  additional  skill  identifier  (ASI). 
This  data  is  also  used  to  prepare  plans  to  provide  the  amount  of  trained 
personnel  required  for  operating  and  supporting  the  new  system  or 
training  device. 

The  BOIP  and  QQPRI  are  associated  documents  (prepared  and  staffed 
together)  that  must  be  approved  and  incorporated  with  the  ORD 
package  at  ORD  approval.  The  formal  documentation  of  the 
BOIP/QQPRI  is  the  combat  developer’s  responsibility. 
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RAM  is  a  measurement  of  system  or  device  effectiveness.  RAM 
requirements  are  assigned  to  systems,  training  equipment,  and  training 
devices  to  ensure  operational  readiness,  performance  of  specified 
functions,  and  economy  of  operation  and  maintenance  within  existing 
policies  and  procedures.  Combat  developers,  training  developers,  and 
materiel  developers  jointly  identify,  collect,  and  document  RAM 
characteristics. 


The  SMMP  is  a  planning  and  management  guide  used  to  ensure  that  all 
domains  of  manpower  and  personnel  integration  (MANPRINT)  are 
considered  throughout  the  development  and  acquisition  process.  The 
SMMP  addresses  all  aspects  of  the  proposed  MANPRINT  effort 
associated  with  the  system  or  training  device.  The  combat  developer 
initiates  the  SMMP  for  new  systems  acquisition,  and  the  training 
developer  initiates  it  in  the  case  of  required  training  devices. 


The  TEMP  is  the  basic  planning  document  for  test  and  evaluation 
requirements  related  to  a  particular  acquisition  program.  The  materiel 
developer  develops  and  updates  the  TEMP  throughout  the  acquisition 
cycle.  The  TEMP  must  have  sufficient  detail  to  explain  the  overall  test 
and  evaluation  (T&E)  program.  Each  acquisition  program  requires  an 
approved  TEMP;  however,  as  in  other  acquisition  and  management 
actions,  the  level  of  detail  for  individual  TEMPs  may  be  tailored 
depending  on  the  particular  acquisition  program's  level  of  effort  and  risks 
associated  with  the  T&E  effort. 


The  NETP  is  required  for  each  developing  system  and  major  training 
device.  It  contains  personnel,  training,  and  cost  information  keyed  to 
major  decision  points  in  the  designated  management  process  for  the 
developing  system  or  training  device.  The  materiel  developer  initiates 
the  NETP,  which  is  prepared  using  the  Army  Modernization  Training 
Automation  System  (AMTAS)  data  base.  The  NETP  covers  all  aspects 
of  training,  answering  the  who,  what,  when,  where,  how,  and  associated 
cost  questions. 
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System  Training  Plan 


Introduction 


Tailoring 


Purpose 


The  STRAP  is  the  master  training  plan  for  a  new/improved  system.  It 
documents  the  results  of  early  training  analyses  covering  specifically 
who  requires  training,  what  tasks  need  to  be  trained,  and  when,  where, 
and  how  the  proponent  will  conduct  training.  The  training  developer 
prepares  the  STRAP  with  input  from  the  combat  developer  and  the 
materiel  developer. 


Although  the  STRAP  is  normally  required  for  each  new  or  improved 
materiel  system,  it  may  be  abbreviated  depending  on  the  complexity  of 
the  proposed  system.  Specific  requirements  for  any  given  STRAP  or  for 
the  possibility  of  a  waiver  of  the  STRAP  for  minor  systems  may  be 
obtained  from  the  System  Training  Integration  Division  (STID),  Training 
Development  and  Analysis  Directorate  (TDAD),  HQ  TRADOC. 

Also,  a  STRAP  may  be  required  for  major  NSTDs.  The  proponent 
training  developer  should  coordinate  with  ATSC  to  determine  STRAP 
requirements  for  NSTDs. 


The  STRAP  has  the  following  purposes: 

•  Plan  for  all  necessary  system-  and  device-related  training  and 
training  support. 

•  Establish  milestones  for  training  development  requirements. 

•  Identify  and  document  training  support  resource  requirements. 

•  Establish  the  basis  for  assessment  of  training  subsystem 
development  progress  in  support  of-- 

Requirements  Review  Committee  (RRC)  reviews. 

Integrated  logistics  support  (ILS)  reviews. 

Training  test  support  packages  (TTSPs). 

Milestone  decision  reviews  (MDRs). 

Type  classification. 
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The  STRAP  is  initiated  when  the  need  for  a  new  or  modified  system  has 
been  identified.  Training  constraints  and  initial  training  strategies  are 
documented  in  the  STRAP  and  used  to  input  the  system's  ORD. 

For  NSTDs  the  STRAP  is  developed  on  an  as-required  basis  and  is 
initiated  at  the  time  of  the  strawman  ORD.  ATSC,  in  conjunction  with 
STID,  determines  for  an  NSTD  the  requirement  for  a  STRAP. 

Since  most  STRAPs  will  be  developed  for  new  systems,  the  process 
described  here  is  for  a  new  system  STRAP.  If  a  STRAP  for  an  NSTD  is 
required,  the  development  process  is  the  same,  but  the  information 
requested  will  be  pertinent  to  the  training  device  and  will  be  used  to 
input  training  device  requirements  documentation. 


The  STRAP  is  an  evolving  document  that  starts  at  the  beginning  of  the 
system  research  and  development  process  (MNS  approval).  The 
training  developer  determines  the  initial  training  concept  for  the  system 
and  initiates  an  outline  of  the  STRAP.  As  the  STRAP  becomes  more 
detailed  with  the  information  gained  through  system  studies,  MANPRINT 
analyses,  logistic  support  analysis  (LSA)  data  development,  system  and 
device  operational  testing,  and  actions  performed  under  the  systems 
approach  to  training  (SAT),  the  data  is  used  to  input  training  information 
to  the  system  requirements  documentation.  This  process  is  shown 
below. 
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The  information  found  in  the  STRAP  is  used  throughout  the  system  and 
training  subsystem  development  process.  A  key  document  supporting 
STRAP  development  is  the  TTSP,  which  is  documented  in  paragraph  7 
of  the  STRAP.  Data  elements  include  task  lists,  target  audience 
description,  and  training  concepts.  Specifically,  this  information  supports 
development  of  plans  for  testing  the  system  devices. 


The  STRAP  content  varies  throughout  the  system  development  process 
as  training  plans  and  strategies  change.  An  initial  STRAP  will  contain 
the  following  information: 

•  Summary  of  system  description. 

•  Assumptions. 

•  Training  concept. 

•  Training  device  strategy. 

•  Training  constraints. 

•  Summary  of  significant  training  issues  at  risk. 

The  format  for  the  STRAP  and  its  associated  annexes  is  contained  in 
TRADOC  Reg  351  -9,  System  Training  Development. 


AR  71  -2,  Basis  of  Issue  Plan  (BOIP)  and  Qualitative  and  Quantitative 
Personnel  Requirements  Information  (QQPRI) 

AR  351-9,  Systems  Training  Development 

AR  602-2,  Manpower  and  Personnel  Integration  (MANPRINT)  in  the 
Materiel  Acquisition  Process 


Nonsystem  Training  Device  Operational  Requirements  Document, 

pg.  3-9 


System  Operational  Requirements  Document,  pg.  4-9 
Training  Device  Requirements  Data  Package,  pg.  4-26 
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Tne  BOIP/QQPRI  process  is  ongoing  throughout  the  materiel 
development  process.  The  BOIP  and  QQPRI  are  associated  documents 
that  are  required  for  developmental  actions  that  result  in  the  introduction 
of  new  materiel  systems  into  the  U.S.  Army  inventory.  Responsibility  for 
preparation  and  coordination  of  the  BOtP/QQPRI  for  developing  systems 
belongs  to  the  proponent  combat  developer  with  assistance  from  the 
training  developer  and  the  materiel  developer.  This  information  map 
describes  the  process  and  provides  an  explanation  of  how  the  basis  of 
issue  and  personnel  requirements  are  integrated  with  the  materiel 
system  documentation  development. 


The  BOIP  is  a  planning  document  that  indicates  where  the  system  and 
support  equipment  are  to  be  located,  the  number  required,  and  other 
equipment  and  personnel  changes  required  as  a  result  of  materiel 
system  fielding. 

The  QQPRI  is  a  compilation  of  organizational,  doctrinal,  training,  and 
personnel  information  used  to  determine  the  need  for  a  new  or  revised 
MOS  or  specialty  skill  identifier  (SSI)  to  support  the  operation  or 
maintenance  of  a  new  materiel  system. 


Training  devices  and  simulators  meeting  the  following  criteria  do  not 
require  a  BOIP/QQPRI: 

•  Will  not  be  type  classified  (TC). 

•  Will  be  contractor-maintained. 

•  Will  be  assigned  to  a  table  of  distribution  and  allowances  (TDA). 


System  training  devices  will  be  listed  on  the  BOIP/QQPRI  for  the 
system.  They  do  not  normally  have  their  own  BOIP  or  QQPRI. 


Purpose 


Content 


The  BOIP  and  QQPRI  are  used  to  assist  HQDA  in  establishing  overall 
U.S.  Army  requirements  for  a  materiel  system.  An  approved  BOIP  is 
required  to  be  part  of  the  complete  ORD  package  prior  to  ORD 
approval.  The  BOIP  and  QQPRI  are  developed  and  coordinated  as  a 
package.  They  complement  each  other  to  do  the  following: 

•  Record  resource  requirements  and  program  the  acquisition  and 
distribution  of  the  materiel  system  and  its  associated  training 
support  equipment. 

•  Record  organizational  needs  and  assist  in  determining 
organizational  design. 

•  Establish  or  revise  MOS,  AS  I,  or  civilian  occupations  to  support 
operation  or  maintenance  of  the  materiel  system. 

•  Plan  the  training  of  the  personnel  needed  to  operate,  maintain, 
and  support  the  materiel  system. 


A  completed  BOIP  contains  the  following: 

•  Total  quantity  of  systems  and  support  equipment  required  by  the 
U.S.  Army. 

•  Quantity  to  be  issued  to  each  type  unit. 

•  Associated  items  of  equipment,  by  type  and  quantity,  including 
training  equipment  and  devices. 

•  Personnel  distribution  needed  to  operate  and  maintain  the 
system,  by  skill  and  quantity. 

•  Training  programs  for  the  required  skills. 

•  List  of  systems  displaced  by  the  new  system. 

The  QQPRI  contains  the  following: 

•  Principal  items  of  equipment  associated  with  the  system 
including  training  equipment  and  devices. 

•  Direct  productive  annual  maintenance  man-hours  (DPAMMH)  for 
the  system  and  all  associated  equipment. 
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Ail  MOS/ASI  required  for  operation  or  maintenance  of  the 
system. 

Duty  positions  and  titles  of  personnel  required  for 
operation/maintenance  of  the  system. 

Unique  duties,  tasks,  and  characteristics. 

Personnel  qualifications. 

New  or  revised  MOS  draft  job  descriptions. 


In  developing  the  BOI/BOIP  data,  training  developers  must  assess 
requirements  in  terms  of  how  many  devices  are  needed  at  a  particular 
time  in  a  geographic  area  to  support  the  proponent’s  combined  arms 
training  strategy  (CATS).  This  assessment  considers  personnel  and 
equipment  density  and  other  resource  constraints  such  as  ranges, 
training  area  availability,  and  a  comparison  of  the  costs  of  training  with 
or  without  the  devices  or  other  training  support  equipment. 

An  important  consideration  at  this  time  is  whether  the  devices  will  be 
assigned  to  the  unit’s  tables  of  organization  and  equipment  (TOE)  or  to 
training  support  center  (TSCs)  for  further  distribution  to  units,  as 
required,  for  training.  Devices  issued  through  TSCs  are  assigned  to  a 
TDA.  These  devices  are  documented  as  such  in  the  system  BOIP  even 
though  the  system  itself  supports  a  TOE  unit. 


The  following  figure  depicts  the  relationship  of  the  BOIP/QQPRI  process 
to  the  training  developer’s  input  to  the  system  documentation.  Note  that 
the  training  developer's  input  is  based  on  training  concepts  and 
strategies  documented  in  the  STRAP.  The  combat  developer’s 
BOIP/QQPRI  input  to  the  system  requirements  documents  is  direct  input 
between  the  BOIP/QQPRI  and  system  documentation  processes. 
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The  next  figure  describes  this  relationship  for  an  NSTD.  In  addition  to 
showing  the  BOIP/QQPRI  development  process,  the  relationship  to  the 
developing  NSTD  documentation  and  products  related  to  device  fielding 
are  shown. 
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Training  Concept/ 
Strategy 


Estimate  Total 
Number  off  Devices 
Required 


Determine  Basis  of 
Issue  and  MOS 
Requirements 


As  shown  in  the  previous  figures,  the  BOIP/QQPRI  development  and  the 
documentation  processes  are  derived  from  the  training  concept/strategy. 
If  thorough  analysis  and  documentation  occurred  in  the  development  of 
the  system  STRAP  or  NSTD  MNS,  the  training  developer  can  readily 
determine  where  the  device  is  required  and  the  number  needed  to 
support  the  proponent's  CATS. 


When  the  training  developer  confirms  a  requirement  for  a  training  device 
as  the  preferred  solution  to  a  training  deficiency,  the  requirement  is 
documented  in  the  NSTD  ORD.  The  requirement  for  a  training  device  to 
support  a  materiel  system  is  documented  in  the  system  ORD  (TSR). 

To  input  to  either  of  these  documents,  the  training  developer  estimates 
the  total  number  of  devices  required  to  support  the  proponent’s  CATS. 
Factors  to  consider  in  arriving  at  this  estimate  include  the  following: 

•  Where  the  training  will  take  place  (TRADOC  school,  active  U.S. 
Army  units,  reserve  component  units,  or  other  training  areas). 

•  Where  the  device  will  be  located  (TRADOC  school  only,  active 
U.S.  Army  units,  reserve  component  units,  major  training  centers, 
TSCs,  or  other  locations). 

•  The  current  basis  of  issue  of  any  devices  that  the  new  device  will 
replace. 

This  data,  supported  by  the  initial  analysis  and  the  STRAP,  becomes 
input  to  the  ORD  and  the  preliminary  planning  for  BOIP/QQPRI  data. 


Using  information  gained  from  previous  and  ongoing  analysis,  the 
training  developer  determines  a  rough  estimate  of  device  requirements. 
This  estimate  is  based  on  the  training  strategy  and  the  type  of  units  in 
specific  geographical  locations  requiring  the  device.  Factors  to  be 
considered  in  arriving  at  these  determinations  include  basically  the  same 
questions  covered  during  the  ORD  development  except  at  this  point 
more  information  is  known  regarding  the  device  training  strategy  and  the 
MOS  required  for  operation  and  maintenance. 

Although  a  formal  BOIP/QQPRI  is  not  available  for  inclusion  in  the  ORD, 
sufficient  information  regarding  distribution  and  MOS  requirements  must 
be  provided  to  agencies  in  the  staffing  sequence  to  enable  the 
development  of  reasonably  sound  recommendations. 


5-13 


Submit  BOIP  Feeder 
Data  (BOIPFD)  and 
QQPRI 


Develop 

BOIP/QQPRI 


Submit  BOIP/QQPRI 
to  HQ  TRADOC 


Update  BOIP/QQPRI 


The  materiel  developer  prepares  the  BOIPFD  and  an  initial  QQPRI  and 
forwards  them  to  the  U.S.  Army  Force  Integration  Support  Agency 
(USAFISA)  to  review  the  documents  to  ensure  that  the  BOIPFD  and  the 
QQPRI  are  compatible.  The  documents  are  then  sent  as  a  package  to 
the  U.S.  Army  Combined  Arms  Command  (CAC)  for  coordination  with 
major  Army  commands  (MACOMs)  affected  by  the  new  system.  CAC 
forwards  the  package  to  the  proponent  school,  where  the  combat 
developer  and  the  training  developer  cooperatively  complete  the  BOIP 
and  QQPRI  from  the  initial  QQPRI  and  BOIPFD  information. 


At  this  point  in  the  BOIP/QQPRI  development  process,  the  training 
developer  and  the  combat  developer  follow  the  instructions  in  AR  71-2, 
Basis  of  Issue  Plan  (BOIP)  and  Qualitative  and  Quantitative  Personnel 
Requirements  Information  (QQPRI),  to  formalize  the  data  collected  to 
date  into  BOIP  and  QQPRI  format.  The  combat  developer  at  the 
proponent  school  is  responsible  for  the  formalizing  process.  The 
training  developer’s  responsibility  is  to  provide  accurate  device  and 
training  support  equipment  BOIP/QQPRI  data  to  permit  development  of 
the  formal  documentation. 


After  final  development  of  the  BOIP/QQPRI,  the  proponent 
training/combat  developer  submits  the  package  to  HQ  TRADOC.  HQ 
TRADOC  approves  the  package  after  coordination  with  other  required 
agencies  and  forwards  the  finalized  package  to  HQDA  for  approval. 
This  package  remains  the  approved  BOIP/QQPRI  until  it  is  changed  in 
accordance  with  instructions  in  AR  71-2  or  until  device  fielding.  For 
NSTDs  the  BOIP/QQPRI  accompanies  the  ORD  for  review  by  the 
TDRRC. 


The  BOIP/QQPRI  is  reviewed  throughout  the  system  or  NSTD 
development  cycle.  If  a  major  change  takes  place  during  development 
that  necessitates  a  change  in  distribution  of  the  system  or  nonsystem 
device,  supporting  equipment,  or  operator/maintainer  MOS,  the  package 
is  coordinated  with  appropriate  agencies  and  MACOMs.  When  changes 
are  made  to  the  BOIP/QQPRI,  MOS  decisions  or  distribution  plans  are 
amended  as  necessary. 
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Summary  of 
BOIP/QQPRI 
Actions 


Related  Products 


Comment 


BOIP/QQPRI  data  for  systems,  NSTDs,  and  training  support  equipment 
is  developed  from  the  training  concept  and  strategy  as  documented  in 
the  STRAP  and  system  or  NSTD  requirements  documentation  as 
appropriate.  It  is  formalized  following  the  formats  and  procedures  in  AR 


71-2. 


It  is  important  for  the  training  developer  to  remember  that  the 
BOIP/QQPRI  process  and  the  requirements  documentation  process  are 
parallel  actions  and  are  mutually  supportive.  The  training  developer 
bases  distribution  requirements  for  training  devices  and  training  support 
equipment  on  CATS  and  provides  BOIP/QQPRI  information  to  the 
combat  developer  in  a  timely  manner  to  ensure  proper  documentation 
development. 


Two  products  that  derive  their  input  directly  from  the  BOIP/QQPRI  are 
the  distribution  plan  and  the  NETP.  They  are  used  to  facilitate  fielding 
the  system  and  training  the  personnel  designated  to  operate  and 
maintain  the  system  and  training  devices. 

•  Distribution  plan  -  describes  who  receives  the  device  and  the 
schedule  of  issue  for  NSTDs  that  are  to  be  placed  on  a  TDA. 
There  is  no  set  format  for  a  Distribution  Plan.  The  material 
developer  develops  the  distribution  plan  in  close  coordination 
with  the  training  developer. 

•  NETP  -  if  required  is  developed  by  the  materiel  developer  within 
30  days  after  BOIP/QQPRI  initiation  and  is  coordinated  with  the 
training  developer.  It  identifies  what  training  is  required  for 
introducing  the  systems  into  U.S.  Army  schools,  training  centers, 
and  units.  The  NETP  also  identifies  resources  and  establishes 
responsibilities  for  the  development  and  presentation  of  this 
training.  Most  NSTDs  will  not  require  a  NETP. 


At  the  CAC  and  TRADOC  schools,  the  combat  developer  is  responsible 
for  all  formal  BOIP/QQPRI  actions.  The  training  developer  responsible 
for  developing  STDs  and  NSTDs  should  seek  the  assistance  of  the 
school  combat  developer  and  follow  the  directions  of  AR  71-2  to  comply 
with  BOIP/QQPRI  requirements. 
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Comment  (con.) 


Pertinent 
Regulations  and 
Publications 


Related  Pages 


The  major  focus  of  the  procedures  outlined  herein  are  for  system 
training  devices;  however,  the  basic  processes  are  the  same  for  NSTDs. 


AR  71-2,  Basis  of  Issue  Plan  (BOIP)  and  Qualitative  and  Quantitative 
Personnel  Requirements  Information  (QQPRI) 


Nonsystem  Training  Device  Operational  Requirements  Document, 
pg.  3-9 

System  Operational  Requirements  Document,  pg.  4-9 
New  Equipment  Training  Plan,  pg.  5-34 
Training  Device  Joint  Working  Group  Process,  pg.  7-3 
Other  Joint  Working  Groups,  pg.  7-1 3 
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Reliability.  Availability,  and  Maintainability 


Introduction 


RAM  requirements  are  those  imposed  on  systems  or  devices  to  ensure 
operational  readiness,  performance  of  required  functions,  and  economy 
of  operation  and  maintenance  within  existing  policies  and  procedures. 
RAM  programs  are  applicable  to  materiel  systems;  test,  measurement, 
and  diagnostic  equipment  (TMDE);  training  devices;  and  ancillary 
equipment  developed,  produced,  maintained,  procured,  or  modified  for 
U.S.  Army  use.  The  RAM  elements  are  defined  as  follows: 

•  Reliability  -  the  duration  or  probability  of  failure-free  performance 
of  intended  functions  under  specific  conditions  and  time  intervals. 
This  measurement  is  usually  stated  as  mean  time  between 
failure  (MTBF). 

•  Availability  -  the  percentage  of  time  an  item  is  in  a  mission- 
committable  status. 

•  Maintainability  -  the  capacity  of  an  item  to  be  maintained  in  a 
specified  condition  by  personnel  with  specific  qualifications.  The 
measure  of  ease  of  maintenance  is  quantified  as  mean  time  to 
repair  (MTTR).  The  measure  of  maintenance  burden  is 
quantified  as  the  maintenance  ratio  (MR). 

RAM  characteristics  must  be  quantified  in  the  ORD  and  included  in 
contract  specifications.  This  data  provides  a  basis  for  logistical  support 
analyses  and  the  development  of  support  equipment.  RAM  evaluations 
support  the  exploration  of  alternatives,  selection  of  technical 
approaches,  and  identification  of  technical  risks.  The  information 
presented  here  explains  RAM  requirements  for  NSTDs.  For  a  complete 
and  detailed  explanation  of  RAM  requirements  for  developing  systems, 
see  TRADOC/AMC  Pam  70-11,  RAM  Rationale  Report  Handbook. 

The  materiel  developer  and  training  developer,  in  coordination  with  the 
Combined  Arms  Support  Command  (CASCOM)  determine  RAM 
characteristics  and  goals  for  NSTDs.  The  materiel  developer 
establishes  and  maintains  RAM  programs,  develops  a  RAM  data  base, 
and  ensures  compliance  with  RAM  evaluation  and  established 
standards. 

CASCOM  is  responsible  to  provide  assistance  to  the  proponent  in  the 
development  and  analysis  of  RAM  data  and  to  develop  and  approve  the 
RAM  Rationale  Report  (RRR). 
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Tailoring  Requirements  for  commercially  available  (off-the-shelf)  TADSS  and 

TADSS  meeting  the  criteria  of  a  nondevelopmental  item  (NDI)  are 
documented  using  an  ORD  based  on  an  approved  MNS.  However, 
since  an  NDI  solution  to  a  training  need  minimizes  or  eliminates 
developmental  risk,  a  tailored  RRR  defining  how  the  available  NDI 
solution  meets  the  OMS/MP  at  an  acceptable  level  is  prepared  by 
CASCOM  to  support  the  MDR. 


Process  The  following  are  the  major  documentation  and  analyses  associated  with 

the  RAM  for  developing  NSTDs  through  approval  of  the  ORD: 

•  Operational  Mode  Summary/Mission  Profile  (OMS/MP). 

•  Failure  definition  and  scoring  criteria  (FD/SC). 

•  Materiel  developer  analysis. 

•  Training  developer  analysis. 

•  RRR. 

The  next  figure  is  a  simplified  version  of  the  RAM  development  and 
documentation  process  as  it  relates  to  NSTD  and  system  TADSS 
development. 


JWQ  1  JWG  2 
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Operational  Mode 
Summary/Mission 
Profile  (OMS/MP) 


Materiel  Developer 
Analysis 


CASCOM  and  the  training  developer  prepares  the  OMS/MP,  which 
describes  how  the  training  device  will  be  used. 

•  The  OMS  describes  the  anticipated  mix  of  the  ways  the  device  is 
used  to  support  the  proponent's  CATS.  The  OMS  covers  all 
missions  in  the  MP  and  shows  the  relative  frequency  of  the 
various  missions. 

•  The  MP  is  a  time-phased  description  of  the  operational  events 
and  environments  the  device  experiences  from  the  beginning  to 
the  end  of  a  specific  mission.  The  MP  identifies  tasks,  events, 
duration,  operating  conditions,  and  environment  for  each  phase 
of  the  device’s  mission. 

The  OMS/MP  must  be  developed  at  or  prior  to  JWG  1  as  that  concept 
formulation  can  be  initiated. 


The  materiel  developer  analysis  is  intended  to  identify  overall  design 
and  support  options  and  levels  of  reliability  and  maintainability 
performance  that  are  not  only  technically  achievable  but  also  have 
acceptable  cost,  schedule,  and  risk  characteristics  commensurate  with 
the  training  developer’s  RAM  goals  and  constraints.  The  materiel 
developer  analysis  consist  of  the  following: 

•  A  comparative  analysis  using  a  baseline  comparative  system 
(BCS)  to  determine  probable  reliability  and  maintainability 
characteristics.  The  BCS  compares  a  training  device  similar  to 
the  proposed  device  or,  if  none  exists,  a  hypothetical  device 
made  up  of  assemblies  (components)  having  technology  and 
complexity  similar  to  the  proposed  device. 

•  A  state-of-the-art  analysis,  which  is  intended  to  identify 
opportunities  for  design  improvements  of  the  new  device  in 
comparison  to  the  BCS. 

•  A  materiel  developer  proposal  analysis,  which  analyzes 
alternatives  to  device  design  based  on  mission  and  economic 
considerations  used  to  select  the  proposal  that  best  meets  the 
needs  of  the  U.S.  Army.  The  output  of  this  analysis  is  the 
identification  of  broad  approaches  to  device  design  and  support 
that  appear  to  be  the  most  reasonable  proposal  form  a  technical 
viewpoint. 


5-19 


Training  Developer 
Analysis 


RAM  Rationale 
Report  (RRR) 


The  training  developer  analysis  sets  the  goals  for  the  RAM  program  and 
examines  the  ability  of  the  RAM  requirements  to  successfully  validate 
the  device's  assigned  missions.  The  training  developer  analysis 
contains  the  following: 

•  A  statement  of  the  qualitative  RAM  goals  and  constraints. 

•  Administrative  and  logistics  downtime  (ALDT). 

•  Maintenanr  e  manpower  analysis. 

•  Wartime  mission  accomplishment  validation. 

•  Peacetime  availability/readiness  analysis. 


The  RRR  documents  the  RAM  requirements  and  results  of  RAM-related 
analyses  that  are  performed  throughout  the  device’s  development  cycle. 
The  RRR  is  prepared  by  CASCOM  based  on  information  that  is 
developed  from  the  ORD  and  OMS/MP.  A  synopsis  of  the  executive 
summary  of  this  report  will  be  included  in  the  rationale  annex  of  the 
ORD.  The  RRR  consists  of  ten  paragraphs.  For  NSTDs  paragraphs  1 
through  8  are  completed  between  strawman  ORD  development  and 
JWG  2.  Paragraphs  9  and  10  are  completed  after  the  final  ORD 
approval  if  required  for  modifications  based  on  RAM  updates.  Details 
for  completion  of  these  paragraphs  are  found  in  TRADOC/AMC  Pam  70- 
11. 

The  following  table  provides  a  brief  description  of  each  paragraph  in  the 
RRR  and  identifies  the  activity  responsible  to  assist  CASCOM  in  the 
preparation. 
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RAM  Rational* 

•  Raport  (RRR) 
(con.) 


PARAGRAPH 

DESCRIPTION 

ASSISTING  ACTIVITY 

1.  Executive  Overview 

An  executive  summary  with  user  RAM 
goals  and  constraints  and  a  RAM 
impact  briefing 

Training  Developer  and 
Materiel  Developer 

2.  OMS/MP 

The  operational  mode  summary  and 
mission  profile 

Training  Developer 

3.  FD/SC 

The  failure  definition  and  scoring 
criteria 

Training  Developer 

4.  Materiel  Developer 
Analysis 

An  analysis  of  the  baseline  comparison 
system  and  operating  and  support  cost 

Materiel  Developer 

5.  Training  Developer 
Analysis 

An  analysis  of  operational  effectiveness 
and  supportability 

Training  Developer 

6.  Logistic  Support 
Analysis  (LSA) 

Interlace 

A  copy  of  the  logistic  support  analysis 
record  (LSAR)  'A*  sheet 

Materiel  Developer  and 
Training  Developer 

7.  RAM  Parameters 

Definition  of  the  RAM  parameters  used 

In  the  ORD  and  the  methods  of 
calculating  them 

Training  Developer 

8.  Points  of  Contact 

Name,  address,  and  telephone  number 
of  all  members  of  the  RAM  working 
group 

Training  Developer 

8.  ORD  Update 

An  update  of  the  ORD  RAM  requirements 
based  on  contractor  comments  and 
feedback 

Training  Developer 

10.  Translation  to 
Technical 

Requirements 

Documentation  of  the  procedures  used 
to  translate  the  operational  RAM 
requirements  in  the  ORD  to  technical 
requirements  for  use  in  the  request  for 
proposal  (RFP)  and  contract 

Materiel  Developer 

Partinant  AR  70-1,  Army  Acquisition  Policy 

Populations  and 

Publications  AR  70-10,  Test  and  Evaluation  During  Development  and  Acquisition  of 

Materiel 

AR  702-3,  U.S.  Army  Materiel  Systems  Reliability,  Availability,  and 
Maintainability 

AR  1000-1,  Basic  Policies  for  System  Acquisition 
TRADOC/AMC  Pam  70-11,  RAM  Rationale  Report  Handbook 
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Related  Pages 


Nonsystem  Training  Device  Acquisition  Process,  pg.  2-3 

System  Training  Device  Acquisition  Process,  pg.  2-13 

Nonsystem  Training  Device  Operational  Requirements  Document, 

pg.  3-9 

System  Operational  Requirements  Document,  pg.  4-9 
Annex  C,  Training  Support  Requirements,  pg.  4-20 
Training  Device  Joint  Working  Group  Process,  pg.  7-3 
Other  Joint  Working  Groups,  pg.  7-13 
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System  MANPRINT  Management  Plan 


Ihtroduction 


Tailoring 


Process 


The  SMMP  is  a  dynamic  planning  and  management  document.  The 
SMMP  is  used  by  all  activities  involved  in  the  materiel  development  and 
acquisition  process  to  ensure  that  MANPRINT  issues  are  addressed 
throughout  the  materiel  system’s  or  NSTD’s  life  cycle.  The  SMMP 
qualifies  as  the  human  system  integration  plan  that  is  required  by  DOD. 

The  SMMP  documents  the  data  available,  data  development 
requirements,  methodology,  schedule,  and  sources  for  data  collection 
and  application  to  address  MANPRINT  issues  and  concerns.  This  data 
will  be  used  to  prepare  the  STRAP  for  the  system  or  training  device.  It 
also  provides  the  proponent  with  documentation  that  all  available  data 
has  been  examined  and  a  plan  or  program  established  to  address 
MANPRINT  issues  throughout  the  materiel  acquisition  process.  The 
SMMP  also  does  the  following: 

•  Provides  an  audit  trail  recording  MANPRINT  issues  raised. 

•  Documents  the  data  sources,  analyses,  trade-offs,  and  decisions 
made  throughout  the  materiel  acquisition  process. 

•  Serves  as  documentation  of  what  was  considered  and  why  it  was 
or  was  not  used. 

•  Provides  a  source  of  continuity  to  lessen  the  impact  of  personnel 
turnover  on  the  MANPRINT  effort. 


The  SMMP  is  tailored  for  each  system  or  device  depending  on 
complexity  and  MANPRINT  issues  at  risk. 


The  SMMP  is  prepared  for  each  new  materiel  acquisition  or  major 
materiel  change  (product  improvement)  made  to  a  system  or  NSTD. 
The  SMMP  is  jointly  approved  by  TRADOC  and  the  materiel  developer 
60  days  prior  to  each  MDR.  A  copy  of  the  SMMP  is  provided  to  HQDA 
for  staffing  and  comment. 
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Process  (con.) 


The  SMMP  is  initiated  at  a  MANPRINT  joint  working  group  (MJWG) 
prior  to  program  start-up  and  development  of  the  system  ORD  by  the 
combat  or  developer  when  a  deficiency  requiring  a  materiel  solution  is 
identified.  In  the  case  of  training  devices,  the  MJWG  is  normally 
conducted  as  part  of  joint  working  group  (JWG)  1 .  At  this  point  in  the 
acquisition  process,  the  SMMP  will  be  vague  and,  in  some  areas,  blank. 
Limited  information  may  be  available  on  the  materiel  system  or  device  at 
this  point.  As  the  acquisition  process  progresses,  the  information  will 
become  more  specific  and  definitive.  Initiation  of  the  SMMP  follows  a 
logical  progression  as  follows: 

•  All  potential  data  sources  and  analysis  requirements  are 
identified. 

•  Available  program  guidance  is  reviewed. 

•  Existence  of  predecessor  systems  (or  reference  components)  is 
determined. 

•  The  list  of  data  sources  is  examined  to  determine  which  are 
appropriate  for  the  effort  being  initiated,  are  readily  available,  or 
must  be  generated.  The  availability  of  resources  to  generate  this 
data  is  also  determined.  As  the  program  progresses,  data 
sources  may  be  added  or  eliminated  depending  on  requirements 
and  resources. 

•  The  acquisition  strategy  (which  also  may  be  extremely  vague  at 
this  time)  is  reviewed,  and  priorities  are  set  for  when  data  must 
be  available. 

A  fully  developed  SMMP  may  not  be  required  if  there  is  minimum  impact 
in  the  MANPRINT  area.  The  following  matrix  can  be  used  to  assist  in 
determining  the  level  of  effort  required  for  the  SMMP. 
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Process  (con.) 


Content/Format 


The  SMMP  addresses  all  aspects  of  the  proposed  MANPRINT  effort 
associated  with  the  new  system.  The  format  for  the  SMMP  can  be 
found  in  AR  602-2,  Manpower  and  Personnel  Integration  (MANPRINT) 
in  the  Materiel  Acquisition  Process.  The  SMMP  includes  the  following: 

•  Title/approval  page. 

•  Abbreviated  total  system  description 

System  type  (combat,  combat  support,  combat  service 
support). 
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Content/Format 

(con.) 


Operational/maintenance  concept. 

MOSs. 

Acquisition  strategy 

Acquisition  program  category  (ACAT  I,  II,  III,  IV). 

Acquisition  type  (developmental,  nondevelopmental, 
material  change). 

Deficiencies  and/or  lessons  learned  of  the  predecessor  system. 

Deficiencies,  not  data  sources. 

MANPRINT  parameters 

Threshold  (minimum  acceptable  value). 

Objective  goal  (measurable,  beneficial  increase  in 
capability,  operation,  or  support  above  the  threshold). 

More  detailed  than  ORD. 

MANPRINT  Issues 

Summary  listing  of  issues. 

Issue  (brief  statement  of  issue  and  impact). 

Affected  domains  (all  applicable  domains). 

Responsible  agency  (who  provides  data  to  resolve  the 
issue  or  answer  the  question). 

Data  source  and  projected  availability  (document 
containing  data  to  resolve  issue/question  and  date 
available). 

Findings  (resolution/answer  to  issue). 

Status  (open/closed/monitor). 

MANPRINT  execution 

Time-phased  description  of  how  the  MANPRINT  program 
will  be  executed  in  each  acquisition  phase. 
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AR  385-16,  System  Safety  Engineering  and  Management 

AR  602-2,  Manpower  and  Personnel  Integration  (MANPRINT)  in  the 
Materiel  Acquisition  Process 

Early  Comparability  Analysis  (ECA)  Procedural  Guide  (USAPIC) 


Nonsystem  Training  Device  Acquisition  Process,  pg.  2-3 
System  Training  Device  Acquisition  Process,  pg.  2-13 
System  Operational  Requirements  Document,  pg.  4-9 
System  Training  Plan,  pg.  5-5 
Train:ng  Effectiveness  Analysis  Process,  pg.  6-8 
Training  Device  Joint  Working  Group  Process,  pg.  7-3 
Modification  Management,  pg.  9-1 

Appendix  A,  Nonsystem  Training  Device  Life  Cycle  Model,  pg.  A-1 
Appendix  B,  System  and  Training  Subsystem  Life  Cycle  Model,  pg.  B-1 
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Testing  and  Evaluation 


Introduction 


Types  of  Tests 


Tailoring 


T&E  efforts  are  integral  elements  of  the  overall  materiel  acquisition 
process.  The  training  developer  provides  documentation  and  frequent 
input  to  operational  testing,  force  development  testing,  joint  user  testing, 
technical  testing,  and  evaluations  as  appropriate.  The  T&E  program  for 
a  developing  system  or  training  device  is  detailed  in  the  TEMP.  This 
information  map  explains  established  programs  that  ensure  availability  of 
informal,  formal,  immediate,  and  deliberate  means  of  evaluating  and 
improving  systems,  training  subsystems,  and  nonsystem  training  devices 
(NSTDs).  It  also  provides  an  overview  of  the  TEMP,  operational  issues 
and  criteria  (OIC),  and  the  TTSP. 


There  are  several  different  types  of  tests  that  can  be  conducted 
throughout  the  development  of  materiel  systems  and  training  devices. 
The  following  are  those  that  the  training  developer  may  become  involved 
in  and  (if  part  of  the  program’s  T&E  effort)  that  must  be  outlined  in  the 
TEMP: 

•  Early  user  test  and  experimentation  (EUT&E). 

•  Initial  operational  test  and  evaluation  (IOT&E). 

•  Follow-on  operational  test  and  evaluation  (FOT&E). 

•  Force  development  test  and  experimentation  (FDT&E). 

•  Joint  user  testing. 

•  Technical  testing  (TT). 


Test  and  evaluation  programs  are  tailored  for  each  materiel  acquisition 
program.  The  level  of  detail  for  the  TEMP  and  the  number  of  tests  to  be 
conducted  for  a  training  device  can  normally  be  expected  to  be  less 
than  that  required  for  a  major  weapon  system.  Common  sense  should 
be  applied  in  laying  out  and  documenting  the  T&E  program.  In  some 
circumstances  (for  example,  a  nondevelopmental  item  (NDI)  training 
device)  there  may  be  no  requirement  for  operational  or  technical  testing. 
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Early  User  Test  and 

Experimentation 

(EUT&E) 


Initial  Operational 
Test  and  Evaluation 
(IOT&E) 


Follow-on 
Operational  Test 
and  Evaluation 
(FOT&E) 


Force  Development 
Test  and 
Experimentation 
(FDT&E) 


Joint  User  Testing 


Technical  Testing 
(TT) 


This  phase  of  testing  employs  user  personnel  during  the  Concept 
Exploration  and  Definition  phase  prior  to  entering  Demonstration  and 
Validation/Engineering  and  Manufacturing  Development.  The  purpose  is 
to  test  a  materiel  concept,  support  planning  for  training  and  logistics, 
identify  interoperability  problems  and  future  testing  requirements,  and 
provide  data  for  an  operational  evaluation  to  support  the  milestone  I/ll 
decision.  Specific  tests  or  experiments  during  EUT&E  may  include  an 
innovative  test  (IT),  FDT&E,  operational  feasibility  test  (OFT),  or  other 
designated  tests. 


IOT&E  is  a  field  evaluation  employing  typical  user  personnel  under 
realistic  operational  conditions  and  typical  evaluation.  It  is  conducted 
during  the  Demonstration  and  Validation/Engineering  and  Manufacturing 
Development  phase  to  assess  operational  effectiveness  and  suitability  of 
military  materiel  prior  to  a  full  production  decision  (milestone  III). 


FOT&E  is  conducted  after  a  full  production  decision  to  obtain  information 
absent  in  previous  operational  tests  and  evaluation  or  to  verify  correction 
of  materiel,  training,  or  concept  deficiencies. 


FDT&E  is  a  range  of  tests  and  experiments  conducted  with  troops  under 
field  conditions  to  support  both  materiel  system  acquisition  and  the 
development  of  doctrine,  training,  organizations,  logistics,  and  materiel 
concepts/requirements.  These  tests  support  definition  of  the  materiel 
requirement  or  assess  the  doctrine,  training,  organization,  and  logistics 
developed  for  the  materiel  system. 


The  U.S.  Army  participates  in  joint  user  testing  with  one  or  more  of  the 
other  services  to  evaluate  systems  or  concepts  having  an  interface  with 
another  service  or  requiring  a  test  environment  of  another  service. 


Technical  testing  is  conducted  within  the  acquisition  process  to  examine 
level  of  performance  versus  design  specifications. 
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Test  and  Evaluation 
Master  Plan  (TEMP) 


ContenVFormat 


Comment 


The  TEMP  is  the  basic  planning  document  for  T&E  related  activities  in  a 
particular  acquisition  program.  The  materiel  developer  develops  and 
updates  the  TEMP  throughout  the  acquisition  cycle.  The  TEMP 
contains  sufficient  detail  to  explain  the  system’s  overall  T&E  program. 
Each  acquisition  program  has  an  approved  TEMP;  however,  as  in  other 
management  actions  and  events,  the  level  of  detail  in  particular  TEMPs 
is  tailored  depending  on  the  program  level  of  effort  and  risks  associated 
with  the  specific  program. 


The  TEMP  is  detailed  to  the  extent  necessary  to  show  the  type, 
duration,  location,  and  schedule  for  planned  testing.  Specifically  the 
TEMP  does  the  following: 

•  Relates  T&E  efforts  to  critical  technical,  operational,  and  training 
issues. 

•  Explains  the  relationship  between  T&E  schedules  and  program 
decision  points. 

•  Addresses  the  T&E  to  be  accomplished  in  each  of  the  acquisition 
management  phases. 

•  Shows  the  test  articles  planned  to  satisfy  test  objectives. 

The  format  and  detailed  information  on  the  content  of  the  TEMP  is  found 
in  DOD  5000.2-M,  Defense  Acquisition  Management  Documentation  and 
Reports.  Requirements  for  testing  in  any  specific  acquisition  program 
will  be  determined  at  the  test  integration  working  group  (TIWG)  (see 
chapter  7). 


The  training  subsystem,  including  embedded  training  capabilities  and 
training  devices,  is  normally  tested  along  with  the  system  and  is  also 
addressed  in  the  system  TEMP.  As  system  development  proceeds  and 
the  requirement  for  training  devices  becomes  more  detailed  in  the 
STRAP,  the  training  developer  must  ensure  that  the  materiel  developer 
updates  the  TEMP  to  include  training-related  test  requirements.  If 
necessary  a  separate  TEMP  is  developed  for  each  training  device  or 
family  of  training  devices  to  track  the  testing  of  the  devices. 
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Operational  Issues 
and  Criteria  (OIC) 


OICs  are  used  to  determine  the  scope,  emphasis,  and  intensity  of  the 
T&E  effort.  This  determination  is  the  basis  for  the  resources  (personnel, 
time,  facilities,  equipment,  instrumentation,  and  funds)  that  must  be 
committed  to  obtain  the  data  to  answer  the  issues  and  evaluate  the  level 
to  which  the  criteria  are  met.  Issues  are  incorporated  into  the  TEMP. 

At  key  milestones  in  any  materiel  acquisition  program,  decision  makers 
must  determine  if  a  materiel  system  will  proceed  into  the  next  phase  of 
acquisition.  Essential  input  to  these  decisions  is  an  independent 
operational  evaluation  that  focuses  on  the  critical  operational  issues  and 
criteria  (COIC)  and  additional  operational  issues  and  criteria  (AOIC). 

•  Questions  on  operational  issues  permit  an  evaluation  of  the 
overall  operational  effectiveness  and  suitability  of  a  materiel 
system. 

•  Criteria  are  standards  by  which  issues  are  evaluated.  These 
elements  in  conjunction  with  the  scope  of  the  planned  T&E  and 
rationale  to  support  selection  of  the  criteria  constitute  the  OIC. 

•  The  two  distinct  levels  of  OIC  (COIC  and  AOIC)  are  interrelated 
and  mutually  supportive  and  assist  in  the  decision  process  for 
acquisition  of  materiel  systems. 


Critical  Operational 
Issues  and  Criteria 


(COIC) 


COIC  are  key  issues,  with  associated  scope,  criteria,  and  rationale,  that 
must  be  answered  to  support  the  next  MDR.  They  are  reviewed  and 
revised/updated  as  required  to  support  subsequent  MDRs.  COICs  are 
developed  by  the  combat  developer  for  developing  systems  and  by  the 
training  developer  for  devices  in  coordination  with  the  TIWG. 


Additional 
Operational  Issues 
and  Criteria  (AOIC) 


AOICs  are  issues,  with  associated  scope,  criteria,  and  rationale, 
developed  by  the  independent  operational  evaluator,  the  combat 
developer,  or  training  developer  to  support  a  complete  assessment  of 
the  system  and/or  device  acquisition  status  at  each  MDR.  They  are 
developed  to  complement  or  support  evaluation  of  the  COIC  as  well  as 
to  provide  for  a  comprehensive  evaluation  of  the  total  system/device. 
AOICs  are  documented  in  the  TEMP. 
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Training  Teat 
Support  Package 
(TTSP) 


Pertinent 
Regulations  and 
Publications 


The  TTSP  is  provided  for  use  in  evaluating  training  on  new  systems  or 
devices.  An  explanation  of  the  development  and  coordination  of  the 
TTSP  is  contained  in  paragraph  7,  TTSP,  of  the  STRAP.  The  TTSP  will 
contain  the  following  as  applicable: 

•  STRAP. 

•  Training  certification  plan. 

•  Training  schedule. 

•  Program  of  instruction  (POI)  for  each  MOS/SSI  affected. 

•  Training  data  requirements. 

•  Army  training  evaluation  plan  (ARTEP)  or  changes  to  ARTEP. 

•  List  of  training  aids,  training  devices,  embedded  training 
components,  and  simulators. 

•  Target  audience  description. 

•  Soldier  training  publications  or  changes. 

•  Crew  drills. 

•  Lesson  plans. 

•  Ammunition,  targets,  and  ranges  required  for  training. 

•  Critical  task  list. 

•  Description  of  how  user  personnel  will  be  trained  for  the  test. 


DOD  5000. 2- M,  Defense  Acquisition  Management  Documentation  and 
Reports 

AR  70-1 ,  Army  Acquisition  Policy 
AR  70-10,  Test  and  Evaluation 
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Related  Pages 


AR  71-3,  User  Testing 

TRADC3  Reg  71-9,  User  Test  and  Evaluation 

DA  Pam  71-3,  Operational  Testing  and  Evaluation  Methodology  and 
Procedures  Guide 


Nonsystem  Training  Device  Acquisition  Process,  pg.  2-3 

System  Training  Device  Acquisition  Process,  pg.  2-13 

Nonsystem  Training  Device  Operational  Requirements  Document, 

pg.  3-9 

System  Training  Plan,  pg.  5-5 
Training  Device  Joint  Working  Group  Process,  pg.  7-3 
Other  Joint  Working  Groups,  pg.  7-13 
Modification  Management,  pg.  9-1 
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New  Equipment  Training  Plan 


Introduction 


Tailoring 


Purpose 


The  NETP  is  used  to  document  the  training  and  training-reiated 
resources  that  will  be  required  for  operators,  maintainers,  and  leaders 
upon  fielding  of  a  new  system  or  (in  some  cases)  a  training  device.  The 
materiel  developer  is  responsible  to  initiate  and  maintain  the  NET P. 
Training  developers  and  users  input  to  the  plan  and,  in  conjunction  with 
the  materiel  developer,  update  it  as  changes  warrant  during  the 
system’s/device's  development  cycle. 


Information  required  for  training  developer  input  to  the  NETP  is  available 
in  the  STRAP.  If  the  STRAP  is  well  written  and  updated  as  required,  it 
should  not  be  a  major  task  to  develop/update  the  NETP. 

System  training  devices  will  not  normally  have  their  own  NETP  but 
rather  will  be  incorporated  into  the  system  NETP.  A  major  NSTD  may 
have  an  NETP,  but  most  NSTDs  may  not  require  an  NETP. 


The  need  for  and  extent  of  new  equipment  training  requirements  are 
determined  by  the  level  of  impact  on  readiness  and  the  skills  and 
experience  of  the  personnel  and  units  scheduled  to  receive  the  new 
equipment.  The  NETP  is  a  management  tool  designed  to  do  the 
following: 

•  Ensure  all  actions  are  identified  and  implemented  for 
development  of  successful  and  comprehensive  training  programs 
for  new  and  improved  equipment. 

•  Identify  who  and  what  will  be  trained. 

•  Identify  how  and  when  initial,  institutional,  sustainment,  and 
doctrine  and  tactics  training  will  be  provided  to  the  active  U.S. 
Army  and  to  the  reserve  components. 

•  Plan  for  the  resources  required  to  conduct  training  on  the  new 
equipment. 
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Process 


Content/Format 


NETPs  are  developed  using  the  AMTAS  centralized  data  base  network. 
The  materiel  developer  is  responsible  for  development  and  maintenance 
of  the  NETP,  while  the  Deputy  Chief  of  Staff  for  Operations  (DCSOPS) 
at  HQDA  is  the  final  approving  authority  for  all  information  in  the  AMTAS 
and  on  the  NETP. 

TRADOC  and  MACOMs  receiving  new  equipment  provide  information  to 
the  materiel  developer  through  AMTAS  for  development  and  update  of 
the  NETP.  The  materiel  developer  will  prepare  the  initial  NETP  within 
30  working  days  after  any  of  the  following  events  takes  place: 

•  Development  of  BOIPFD  and  QQPRI. 

•  Receipt  of  a  draft  requirements  document. 

•  Receipt  of  a  procurement  directive. 

•  Notification  of  intent  to  reenter  equipment  into  the  U.S.  Army 
inventory. 

After  initiation  of  the  NETP,  each  command  will  input  pertinent  data 
within  30  working  days.  Since  the  NETP  is  on  the  automated  system 
(AMTAS),  Commands  submit  suggested  changes  on-line.  The  materiel 
developer  considers  changes  and  incorporates  them  into  the  NETP  or 
provides  justification  for  nonacceptance.  DCSOPS  makes  the  final 
decision  on  differences  between  the  materiel  developer  and  commands. 

NETPs  undergo  annual  updates  at  training  support  work  groups 
(TSWGs).  The  materiel  developer  chairs  the  TSWG.  TRADOC  and 
other  MACOMs  having  input  to  the  NETP  attend  the  TSWG.  (See 
chapter  7). 


The  NETP  contains  personnel,  training,  and  cost  information  keyed  to 
major  decision  points  in  the  acquisition  cycle.  This  information,  as  a 
minimum,  includes  the  following: 

•  A  summary  of  the  training  concept  for  each  receiving  MACOM. 

•  Location  of  major  training  events. 

•  Date,  by  quarter  and  fiscal  year,  that  training  will  begin. 

•  Total  number  of  classes  scheduled  for  each  course. 
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Content/Format 

(con.) 


Number  and  source  of  student  input  for  each  course. 


Training  Developer 
Input  to  the  NETP 


•  Resource  requirements  and  responsibilities  (manpower,  dollars, 
and  facilities)  for  training. 

•  System  and  training  development  milestones  for  the  following: 

BOIP/QQPRI  development. 

New  materiel  briefings. 

Training  literature  development  and  availability. 

MOS  decisions. 

Training  and  doctrine  development. 

Training  device  and  simulator  development. 

Training  aids  and  other  training  support  equipment. 

The  training  developer  should  not  be  concerned  with  the  format  of  the 
NETP.  Since  data  is  input  through  the  AMTAS,  format  is  taken  care  of 
automatically.  The  materiel  developer  makes  printed  copies  available. 


The  TRADOC  proponent  training  developer  provides  the  majority  of  the 
training-related  information  to  the  NETP  and  coordinates  closely  with  the 
combat  developer  and  the  STID,  TDAD,  in  the  office  of  the  Deputy  Chief 
of  Staff  for  Training  (DCST)  at  TRADOC. 

Information  is  derived  from  the  early  comparability  analysis  (ECA)  and 
other  MANPRINT  studies  for  early  input  to  the  NETP.  Training 
information  is  updated  throughout  the  system  development  process 
using  information  from  the  STRAP.  Detailed  instructions  for  providing 
input  to  the  NETP  through  AMTAS  are  provided  in  DA  Pam  350-40, 
Army  Modernization  Training  Plans  for  New  and  Displaced  Equipment. 
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CHAPTER  6 


TRAINING  DEVICE  STUDIES 


Training  Device  Studies 

Overview 


Introduction 


Cost  and 
Operational 
Effectiveness 
Analysis  (COEA) 


Studies  and  analyses  form  the  basis  for  entry  into  a  materiel  acquisition 
program.  Studies  are  performed  for  new  systems,  their  training 
subsystems,  NSTDs,  and  training  programs.  The  following  are  the 
primary  studies/analyses  associated  with  the  acquisition  of  system 
TADSS  and  NSTDs  that  will  be  discussed  in  this  chapter: 

•  Cost  and  operational  effectiveness  analysis  (COEA).  The  COEA 
is  the  responsibility  of  the  proponent  combat  developer. 
Discussion  on  the  COEA  will  consist  of  an  overview  with 
emphasis  on  the  training  developer's  input. 

•  Training  effectiveness  analysis  (TEA).  The  proponent  training 
developer  conducts  the  TEA.  “TEA"  is  a  generic  term  that  refers 
to  analytical  studies  of  alternative  training  concepts  or  media. 
TEAs  are  conducted  as  part  of  COEAs  to  arrive  at  recommended 
training  subsystems.  They  may  also  be  used  for  comparative 
analysis  of  competing  alternatives  for  system  TADSS  or  NSTDs. 

•  Concept  formulation.  Concept  formulation  is  conducted  jointly  by 
the  combat  developer  and  materiel  developer  for  new  systems 
and  by  the  training  developer  and  materiel  developer  for  device 
requirements.  A  concept  formulation  is  conducted  concurrently 
with  and  is  supportive  of  a  COEA  or  TEA. 

Within  this  chapter  each  of  these  studies  will  be  discussed  in  the  level  of 
detail  required  for  a  training  developer.  Where  appropriate,  tailoring  of 
the  process  will  be  presented.  In  this  context  "tailoring"  means  that  if 
the  complete  process  is  not  required  to  be  accomplished  in  each  case, 
opportunities  for  exceptions  or  shortcuts  will  be  identified. 


The  COEA  is  required  for  all  materiel  system  acquisition  programs.  The 
proponent  combat  developer  conducts  the  COEA  concurrently  with  the 
concept  formulation,  which  the  materiel  developer  and  combat  developer 
jointly  conduct.  The  COEA  is  conducted  to  analyze  competing 
alternatives  for  resolution  of  a  recognized  battlefield  deficiency.  The 
initial  COEA  supports  a  milestone  I  decision.  An  updated  COEA  (if 
required  because  of  changes  in  the  system  program)  is  prepared  to 
support  each  ensuing  milestone  decision. 
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Costand 
Operational 
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Analysis  (COEA) 
(con.) 


Training 
Effectiveness 
Analysis  (TEA) 


Concept 

Formulation 


Concurrently  with  the  conduct  of  the  COEA,  the  training  developer 
conducts  a  TEA.  The  purpose  of  the  TEA  is  to  analyze  competing 
training  concepts  for  use  in  the  system’s  training  subsystem.  This  TEA 
is  referred  to  as  "TEA  I”  because  it,  like  the  COEA,  supports  a  milestone 
I  decision. 


The  training  developer  conducts  TEAs  to  support  a  multitude  of  training 
decisions.  Within  the  materiel  acquisition  process,  TEAs  are  conducted 
to  support  milestone  decisions.  TEAs  are  named  for  the  milestone 
decision  of  the  acquisition  program  in  which  they  occur.  For  example,  a 
TEA  conducted  during  phase  0  to  support  a  milestone  I  decision  is 
referred  to  as  a  “TEA  I,"  while  a  TEA  conducted  to  support  a  milestone 
III  decision  takes  place  during  phase  II  and  is  referred  to  as  a  “TEA  III." 

A  postfielding  TEA  (PFTEA)  is  also  conducted  on  each  training  device 
after  the  device  has  been  in  the  field  long  enough  for  its  training 
effectiveness  to  be  evaluated. 


Concept  formulation  is  a  process  jointly  conducted  by  combat 
developers  and  materiel  developers  for  materiel  systems  and  by  training 
developers  and  materiel  developers  for  training  devices.  The  intent  of 
the  concept  formulation  is  to  evaluate  trade-offs  among  alternatives  to 
system  or  device  technologies,  costs,  and  effectiveness  to  determine  the 
best  technical  approach  to  materiel  development  and/or  procurement. 
Concept  formulation  consists  of  three  phases: 

•  Trade-off  determination  (TOD). 

•  Trade-off  analysis  (TO A). 

•  Best  technical  approach  (BTA). 

Training  developer  involvement  in  concept  formulation  for  new  system 
development  is  minimal.  When  conducting  the  system  concept 
formulation,  the  combat  developer  and  the  materiel  developer  should 
use  information  provided  to  the  combat  developer  in  the  TEA  that 
supports  the  COEA. 

For  training  devices  the  training  developer  participates  with  the  materiel 
developer  (usually  simulation,  training,  and  instrumentation  command 
(STRICOM))  in  the  conduct  of  the  concept  formulation.  Upon 
completion  of  the  analysis,  the  training  developer  selects  the  BTA. 
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Cost  and  Operational  Effectiveness  Analysis 


Introduction 


Tailoring 


Purpose 


The  proponent  combat  developer  conducts  the  COEA  for  new  system 
development/procurement.  The  COEA  is  included  in  this  procedural 
guide  because  the  training  developer’s  input  to  the  COEA,  in  the  form  of 
a  TEA,  could  have  a  profound  influence  on  system  design  and 
characteristics.  Design  influence  is  most  apparent  regarding  embedded 
training  capabilities  but  is  also  of  prime  consideration  in  requirements  for 
simulators  and  major  training  devices.  For  these  reasons  the  training 
developer  should  have  a  basic  understanding  of  the  COEA  and  a  more 
complete  understanding  of  the  associated  TEA. 


The  training  developer  should  remember  that  the  combat  developer 
conducts  the  COEA.  With  this  in  mind,  close  coordination  must  be 
effected  to  determine  the  complexity  of  the  new  system  regarding 
operation  and  maintenance.  This  will  have  a  major  bearing  on  the  level 
of  detail  to  which  the  TEA  will  have  to  be  conducted. 

Some  systems  may  have  little  or  no  training  impact  and  will  require  only 
a  minor  TEA  effort  or  no  TEA  at  all. 


The  COEA  is  a  phased  effort  throughout  the  materiel  acquisition 
program.  The  purpose  will  vary  depending  on  which  phase  of  the 
program  the  information  is  being  gathered  to  support. 

•  During  phase  0  the  COEA  is  used  to  evaluate  competing 
alternatives  to  resolve  a  battlefield  deficiency  or  capability  issue. 
Information  provided  is  to  assist  in  a  milestone  I  decision.  This  is 
referred  to  as  "COEA  I." 

•  During  phase  I  the  COEA  provides  decision  makers  with  a 
comparative  evaluation  of  competing  alternatives  for  system 
design,  capabilities,  and  rough  cost  estimates  This  (COEA  II) 
leads  to  a  milestone  II  decision. 

•  COEA  111,  supporting  a  milestone  III  decision,  is  usually  one  that 
updates  cost  estimates  since  by  this  time  the  system  design 
approach  has  typically  been  chosen. 
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Purpose  (con.) 


Process 


Content/Format 


Training  Developer 
Input 


•  COEA  IV  is  prepared  for  a  milestone  IV  decision.  The  purpose 
of  this  COEA  is  to  consider  costs  and  other  consequences 
involved  in  modification  to  the  system. 

If  there  are  few  changes  since  the  initial  COEA  was  conducted,  there 
may  not  be  a  need  for  other  COEAs  during  system  development.  TEAs 
should  be  prepared  or  updated  to  support  each  required  COEA. 


The  phases  of  COEA  development  are  tied  to  the  system  requirements 
documentation.  The  COEA  and  each  update,  if  required,  are  to  support 
milestone  decisions  as  shown  below. 


Hie  content  and  format  for  a  COEA  are  explained  in  detail  in  DOD 
5000.2-M,  Defense  Acquisition  Management  Documentation  and 
Reports. 


The  training  developer  has  minimal  input  to  the  basic  conduct  or 
documentation  of  the  COEA;  however,  a  TEA  will  be  appended  to  the 
COEA.  The  conduct  of  this  TEA  is  the  responsibility  of  the  training 
developer.  The  results  of  the  TEA  may  have  a  major  impact  on  system 
design  and  cost,  particularly  if  the  TEA  shows  that  the  preferred  training 
strategy  is  through  the  use  of  embedded  training  or  major  simulators  or 
devices. 
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The  TEA  for  the  system  follows  much  the  same  process  as  the  COEA 
does  for  the  system.  This  is  logical  since  the  TEA  is  an  enclosure  to  the 
COEA  and  therefore  is  updated  as  the  COEA  is  updated.  The  figure 
below  shows  this  process. 


The  TEA  conducted  to  support  the  COEA  for  a  milestone  I  decision 
evaluates  all  competing  training  strategies.  As  the  system  design 
strategy  becomes  more  firm  and  succeeding  COEAs  are  more 
concerned  with  cost  than  competing  designs,  the  updated  TEAs  provide 
more  firm  cost  estimates  for  the  selected  training  concept. 


The  remainder  of  this  chapter  addresses  TEAs  for  training  devices  and 
concept  formulation.  For  developing  systems  there  will  be  a  TEA 
conducted  to  support  the  COEA.  A  TEA  will  also  be  conducted  in 
support  of  a  concept  formulation  for  any  training  device  that  is  identified 
as  required  for  the  training  subsystem.  TEAs  conducted  to  support 
design,  development,  and  procurement  of  system  TADSS  are,  in 
essence,  the  same  as  those  conducted  to  support  NSTD  acquisition 
programs.  See  Training  Effectiveness  Analysis  beginning  on  page  6*8 
for  system  TADSS  TEA  requirements. 
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Training  Effectiveness  Analysis  Process 


Introduction 


Tailoring 


Types  of  TEA*  in 
the  Materiel 
Acquisition  Process 


A  TEA,  in  the  generic  sense,  is  a  training  study.  The  study  may  be 
conducted  at  any  time  that  a  problem  is  evident  or  anticipated  in  a 
training  or  performance  environment.  Within  the  materiel  acquisition 
process,  the  training  developer  is  primarily  concerned  with  those  TEAs 
that  support  milestone  decisions  in  the  development  cycle  of  new 
materiel  systems  or  TADSS.  TEAs  may  be  very  limited  in  scope  and 
conducted  by  the  proponent  training  developer  or  may  be 
comprehensive  studies  requiring  a  detailed  study  plan  and  the 
assistance  of  outside  agencies  or  contractors.  The  extent  of  the  TEA  is 
dependent,  in  large  part,  on  the  complexity  of  the  developing  materiel  or 
its  expected  use. 

Detailed  information  pertaining  to  studies  for  materiel  systems  and 
NSTDs  is  found  in  TRADOC  Reg.  350-32,  The  TRADOC  Training 
Effectiveness  Analysis  (JEA)  System. 


Some  developing  systems  may  have  no  impact  on  training.  In  this  case 
there  may  be  no  need  for  a  TEA.  The  training  developer  may  request  a 
waiver  of  the  TEA  requirement  from  the  Systems  Training  Integration 
Division  (STID),  Training  Development  and  Analysis  Directorate  (TDAD), 
HQ  TRADOC.  In  some  cases  TEAs  may  be  deferred  until  there  is 
enough  information  from  combat  development  studies  to  define  the 
training  mission. 

In  the  case  of  training  devices,  a  waiver  of  the  TEA  requirement  may  be 
requested  through  ATSC.  There  are  four  types  of  TEAs  associated  with 
the  materiel  acquisition  process  based  on  the  full-scale  development 
model  (see  chapter  1).  Each  TEA  is  an  update  and  refining  of  the 
previously  conducted  TEA.  Since  training  devices  are  normally 
developed  and  procured  under  a  tailored  management  model,  the  TEA 
process  should  be  tailored  accordingly. 


TEAs  are  conducted  in  the  materiel  acquisition  process  to  support 
milestone  decisions.  For  materiel  system  acquisition,  TEAs  are 
conducted  and  updated  to  support  the  COEA;  therefore,  time  lines  are 
dictated  by  the  system  development  program  (see  previous  information 
map,  COEA). 
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Development  and  procurement  of  training  devices  (system  or  NSTD) 
make  up  a  materiel  acquisition  program  that  will  normally  require  its  own 
TEA  and  concept  formulation.  Within  this  process  TEA.s  are  identified 
by  the  program  acquisition  milestone  decision  that  they  support.  There 
are  four  phases  of  TEA  development  (TEA  I  through  TEA  IV).  Each 
requires  analysis  to  document  information  pertinent  to  decision  makers 
at  each  milestone. 

•  TEA  I  is  conducted  during  Dhase  0,  Concept  Exploration  and 
Definition,  to  provide  information  for  a  milestone  I  decision.  At 
this  point  the  TEA  explores  competing  concepts  and  technologies 
available  or  projected  to  meet  training  mission  requirements. 

TEA  I  supports  the  concept  formulation,  which  is  conducted 
concurrently. 

•  TEA  II  is  conducted  during  Phase  I,  Demonstration  and 
Validation,  to  provide  input  to  the  milestone  II  decision.  The 
TEA  II  scope  may  be  adjusted  depending  on  the  extent  of 
understanding  of  the  new  device  after  concept  formulation  has 
been  completed  and  the  BTA  has  been  selected.  At  this  time, 
the  training  developer  can  get  more  firm  information  on  the  costs 
associated  with  the  selected  alternative. 

•  TEA  III,  conducted  during  Phase  II,  Engineering  and 
Manufacturing  Development,  is  a  comprehensive  cost  and 
training  effectiveness  type  of  analysis  or  an  update  of  such  an 
analysis.  It  is  conducted  to  provide  input  to  the  milestone  III 
decision.  It  directly  addresses  issues  bearing  upon  the  milestone 
II  decision. 

•  TEA  IV  is  performed  during  Phase  III,  Production  and 
Deployment.  The  purpose  of  this  TEA  is  to  determine  whether 
major  modifications  must  be  made  to  a  device  still  in  production. 

•  A  PFTEA  is  conducted  when  a  device  has  been  in  the  field 
sufficient  time  for  a  training  program  to  be  stabilized  (normally 
within  18-24  months  of  fielding).  It  can  assess  the  effectiveness 
of  the  training  program  and  the  TADSS  within  the  program,  or  it 
may  only  address  a  specific  device.  This  TEA  is  not  technically 
a  part  of  the  acquisition  program  but  is  required  and  should  be 
programmed  by  the  proponent  school. 

The  above  explanation  of  the  types  of  TEAs  is  based  on  the  full-scale 
development  model.  Most  training  devices  are  developed/procured 
under  a  tailored  model  (see  chapter  1).  For  this  reason  it  is  rare  that 
the  four  TEAs  would  be  conducted  for  any  single  device.  Tailoring  of 
the  TEA  process  should  be  consistent  with  the  tailored  management 
model  that  is  used. 
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Process 


TEAs  in  support  of  COEAs  for  developing  systems  are  performed  or 
updated  as  required  to  support  the  specific  developing  system.  The 
training  developer  will  effect  coordination  with  the  combat  developer  and 
STiD  to  determine  these  requirements. 

ATSC  prescribes  the  conduct  of  TEAs  for  TADSS  (system  devices  or 
NSTDs)  after  coordination  with  appropriate  elements  of  HQ  TRADOC. 
Upon  submission  of  a  strawman  ORD  (for  NSTDs)  or  a  draft  training 
device  requirements  data  package  (for  system  devices)  (see  chapter  4), 
ATSC  will  notify  the  proponent  training  developer  of  the  type  and  scope 
of  TEA  that  is  required. 

Since  developing  training  devices  normally  follow  a  tailored  management 
model  that  seeks  a  combined  milestones  I  and  If  approval  at  completion 
of  phase  0,  the  training  developer  will  normally  be  requested  to  perform 
a  TEA  I/ll.  On  the  other  hand,  if  a  milestone  III  decision  is  being  sought 
at  the  completion  of  phase  0,  a  TEA  l/lll  will  be  in  order.  This  might  be 
the  case  for  a  nondevelopment  item  (NDI)  that  could  feasibly  go  straight 
to  production  and  employment  after  initial  studies  have  been  completed. 
(Engineering  and  manufacturing  development  would  not  be  required  for 
an  nondevelopmental  item  (NDI).) 

The  figure  below  shows  tht  normal  process  under  a  tailored  NSTD 
model. 


The  key  point  to  remember  from  this  graphic  is  that  the  TEA  supports 
concept  formulation,  which  in  turn  supports  requirements  documentation 
so  that  a  favorable  milestone  decision  can  be  made  allowing  the 
program  to  proceed  into  the  next  development  phase. 

If  the  initial  TEA  is  sufficient  to  proceed  through  the  development  and 
acquisition  process,  no  further  updates  wiil  be  required.  However,  if 
circumstances  dictate,  ATSC  will  direct  additional  TEA  efforts. 
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Concept  formulation  consists  of  a  series  of  analytical  studies  performed 
by  the  materiel,  combat,  and  training  developers  to  determine  the  BTA 
to  develop  and  procure  the  most  cost-,  operational-,  and  training- 
effective  system  or  training  device.  A  concept  formulation  is  performed 
for  a  new  system,  for  each  training  device  requirement  identified  in  the 
training  subsystem,  and  for  each  NSTD.  The  results  of  the  concept 
formulation  are  documented  in  the  concept  formulation  package  (CFP). 

The  elements  of  the  CFP  are  the  same  for  systems  and  devices,  except 
that  the  COEA  for  the  system  is  considered  a  part  of  the  CFP,  whereas 
with  training  devices  the  TEA  is  considered  a  separate  effort.  Both  the 
COEA  and  the  TEA  are  conducted  ^currently  with  concept  formulation 
and  are  supportive  of  the  BTA. 

Training  developer  input  to  the  system  CFP  is  minimal.  The  TEA  that  is 
included  in  the  COEA  is  the  primary  training  developer  input. 
Accordingly,  this  information  map  will  concentrate  on  concept 
formulation  for  training  devices  and  not  for  systems. 


Although  the  concept  formulation  for  training  devices  is  to  be  jointly 
conducted  by  the  training  developer  and  the  materiel  developer, 
STRICOM  normally  performs  the  entire  process  through  a  services 
contract.  The  training  developer  needs  only  to  maintain  close 
coordination  with  STRICOM  and  to  review  each  phase  of  the  process  for 
concurrence  with  the  direction  in  which  the  studies  are  proceeding. 


The  CFP  establishes  technical  and  economic  specifications  to  satisfy  the 
stated  requirement.  The  training  developer  and  the  materiel  developer 
use  information  in  the  CFP  to  establish  technical  and  cost  specifications 
for  the  training  device. 


Three  analyses  are  conducted  as  concept  formulation.  The 
documental  -  1  of  these  three  analyses  comprises  the  CFP: 

•  TOD  -  conducted  by  the  materiel  developer. 
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TOA  -  conducted  by  the  training  developer. 

BTA  •  conducted  by  the  materiel  developer  with  assistance  from 
the  training  developer.  The  training  developer  selects  the  BTA 
from  the  alternatives  presented. 


The  materiel  developer  conducts  the  TOD  for  a  training  device  with 
assistance  from  the  training  developer.  It  contains  the  following: 

•  A  description  of  the  individual  technical  approaches. 

•  Evidence  that  the  proposed  technical  approach  is  engineering 
rather  than  experimental  (includes  technical  risks). 

•  Trade-offs  for  the  suggested  approach. 

•  Estimated  life  cycle  costs. 

•  Recommended  technical  approach. 

The  TOD  documentation  includes  technical  analyses  or  trade-offs;  risks; 
capabilities  needed;  costs;  schedules;  integrated  logistics  support  (ILS) 
requirements;  estimated  total  Army  manpower  requirements;  health, 
safety,  and  human  factors  engineering  (HFE)  requirements;  and 
ecological  factors.  Much  of  this  information  is  derived  through  the 
manpower  and  personnel  integration  (MANPRINT)  process. 


The  training  developer  prepares  the  TOA  with  assistance  from  the 

materiel  developer.  It  contains  the  following: 

•  Mission  and  performance  envelopes  with  justification  and 
rationale. 

•  Analysis  of  system  or  device  trade-offs,  risk,  development 
schedules,  and  logistic  support. 

•  Selection  of  the  BTA  from  an  operational  and  ILS  perspective. 

•  Description  of  the  environmental  and  ecological  factors  and 
health,  safety,  and  HFE  requirements  that  the  U.S.  Army  must 
consider  in  fielding  the  system  or  device. 

NOTE:  The  training  developer  will  not  normally  be  required  to  perform 

this  analysis  (see  "Tailoring"). 


6-13 


Best  Technical 
Approach  (BTA) 


Comment 


Training 
Effectiveness 
Analysis  (TEA) 


The  materiel  developer  prepares  the  BTA  with  assistance  from  the 
training  developer.  It  contains  the  following: 

•  A  description  of  the  BTA  and  ILS  concepts  based  on  the  results 
of  the  TOD  and  TOA. 

•  Evidence  that  the  proposed  BTA  is  engineering  rather  than 
experimental. 

•  Estimated  cost. 

•  Total  Army  manpower  requirements. 

•  Procurement  and  scheduling  estimates. 

•  Recommendation  on  project  management. 

•  Draft  environmental  impact  statement. 


STRICOM  has  the  responsibility  to  conduct  concept  formulation  for  all 
training  devices  (system  devices  and  NSTDs).  The  system  program 
executive  officer/project  manager  (PEO/PM)  normally  provides  funding 
for  concept  formulation  for  system  training  devices.  For  NSTDs  funds 
come  from  the  TMA  R&D  dollars  allocated  for  development  of  NSTDs. 


As  previously  stated  the  training  developer  is  responsible  for  the  TEA 
that  is  part  of  the  COEA  effort  of  the  system.  It  considers  the  following 
in  its  analysis: 

•  Tasks  and  missions  to  be  performed. 

•  Conditions  under  which  the  tasks  must  be  performed. 

•  Programmed  capabilities  to  perform  tasks  and  resulting 

deficiencies. 

•  Cost  alternatives. 

The  TEA  documents  the  comparative  effectiveness  of  alternative  means 
of  meeting  a  training  need  or  requirement  and  the  cost  of  developing, 
producing,  distributing,  and  sustaining  each  alternative.  For  more 
information  on  the  TEA,  see  the  previous  information  map  (TEA). 
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The  TOD,  TOA,  and  BTA  are  normally  done  in  successive  order; 
however,  some  overlap  of  effort  will  usually  occur. 


Concept  formulation  for  each  device  begins  when  sufficient  information 
is  obtained  from  the  system  concept  formulation,  the  early  comparability 
analysis  (ECA),  and,  if  necessary,  the  logistical  support  analysis  (LSA) 
data.  A  draft  training  device  requirements  data  package  (chapter  4)  is 
submitted  to  ATSC,  and  JWG  1  is  scheduled  (chapter  7).  Completion  of 
the  device  CFP  through  BTA  is  the  basis  for  the  conduct  of  JWG  2  for 
the  training  device.  The  next  figure  shows  the  phasing  of  the  concept 
formulation  for  the  materiel  system  and  its  associated  training  devices. 


H  device  concept  formulation  Is  complete  before 
ORD  approval,  the  devioe  may  be  developed 
and  procured  under  the  system  contract  using 
the  system  RFP,  or  It  may  be  developed  and 
procured  under  separate  contract  using  a 
separate  RFP. 


(?)  If  devioe  concept  formulation  is  complete  after 
ORD  approval,  the  device  may  be  developed 
and  procured  under  a  modification  to  the 
system  contract,  or  K  may  be  developed  and 
procured  under  separate  contract  using  a 
separate  RFP. 
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Process  for  System  The  phasing  of  the  CFPs  leading  to  a  request  for  proposal  (RFP)  for  the 

TADSS  (con.)  training  devices  in  this  figure  assumes  that  the  requirements  for  the 

devices  were  identified  early  in  the  system  documentation  development 
process  and  included  in  the  system  MNS  and  ORD.  When  the 
proponent  training  developer  is  ready  to  initiate  JWG  1  for  a  training 
device  concept  formulation,  a  training  device  requirements  data  package 
is  forwarded  by  memorandum  to  ATSC  and  STRICOM.  The  training 
device  requirements  data  package  should  contain  the  following: 

•  The  system  training  strategy.  This  is  extracted  from  the  STRAP, 
or  the  STRAP  is  attached  to  the  memorandum. 

•  The  device  strategy  (part  of  the  STRAP). 

•  The  tasks  to  be  trained. 

•  A  target  audience  description  (military  occupational  specialty 
(MOS),  active  or  reserve  components). 

•  The  proposed  training  environment  (local  training  area  (LTA), 
unit,  institution,  etc.). 

•  Training  constraints. 

•  The  essential  functional  characteristics  of  the  device. 

•  Reliability,  availability,  and  maintainability  (RAM)  parameters  for 
the  training  device. 

As  part  of  the  concept  formulation,  STRICOM  determines  the  most 
appropri;  3  contracting  approach  (for  example,  incorporate  the  device 
requirement  into  the  system  contract  or  execute  a  separate  contract)  for 
device  development  and  procurement. 

If  more  than  one  training  device  is  associated  with  the  materiel  system, 
each  training  device  requires  its  own  concept  formulation.  Concept 
formulation  for  the  separate  devices  may  be  conducted  separately  or 
concurrently  depending  on  sufficiency  and  availability  of  information  to 
the  training  developer  to  support  JWG  1  conduct  and  initiation  of  the 
process. 

If  the  requirement  for  system  TADSS  is  identified  after  ORD  approval, 
documentation  of  the  rec,  'irement  follows  the  procedures  for  NSTD 
requirements. 
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Process  for 
Nonsystem  Training 
Device  (NSTD) 


Comment 


Pertinent 
Regulations  and 
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Concept  formulation  for  NSTDs  is  conducted  essentially  the  same  as  for 
system  TADSS.  A  key  difference  in  the  process  is  that  the  requirements 
documentation  is  impacted  by  the  concept  formulation.  NSTD  concept 
formulation  supports  development  of  an  ORD  to  permit  a  milestone 
decision  leading  to  an  RFP  for  device  development/procurement. 

The  supporting  TOD,  TOA,  and  BTA  are  normally  done  in  succession, 
but  some  overlap  may  occur.  The  TEA  requires  information  from  the 
TOD,  TOA,  and  BTA,  but  it  is  conducted  concurrently  and  used  as  input 
to  the  device  ORD  following  JWG  2.  The  figure  below  shows  the 
phasing  of  the  concept  formulation  for  NSTDs. 


JWO  1  JWG  2 


STRAWMA 

ORD 

N  DRAFT  ORD 

TOD  h - 

*  1  TOA  1 - 

- 1  BTA  | - 

m  1 - TEA - 1  » 

Although  the  BTA  is  selected  at  JWG  2,  the  documentation  of  the  CFP 
is  completed  later  in  the  process.  It  is  essential  that  BTA  selection  take 
place  at  JWG  2  to  allow  STRICOM  to  develop  costing  information.  The 
training  developer  normally  selects  the  BTA  as  part  of  the  JWG. 


AR  70-1 ,  Army  Acquisition  Policy 

AR  350-38,  Training  Device  Policies  and  Management 

TRADOC  Reg  350-42,  TRADOC  Training  Effectiveness  Analysis  (TEA) 
System 
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CHAPTER  7 

JOINT  WORKING  GROUPS 


Joint  Working  Groups 

Overview 


Introduction 


Types  of  JWGs 


A  joint  working  group  (JWG),  for  materiel  acquisition  purposes,  consists 
of  representatives  from  the  combat,  materiel,  and  training  development 
communities  and  selected  subject  matter  experts  meeting  in  a 
prescribed  forum  for  direct  communication.  The  purpose  is  to  facilitate 
coordination  of  requirements  documentation  and  related  actions  in  the 
materiel  acquisition  process.  As  such,  the  JWG  brings  all  interested 
parties  to  one  location  to  determine  responsibilities  and  milestones  and 
to  prepare  or  coordinate  requirements  and  supporting  documentation. 
The  JWG  is  not  merely  a  meeting  of  interested  parties,  but  more  of  a 
process  whereby  close  and  continual  coordination  can  be  effected 
throughout  a  training  device  development  and  acquisition  program. 


This  chapter  provides  information  on  the  types  of  JWGs  in  which  the 
training  developer  will  routinely  be  involved  during  acquisition  programs 
for  new  systems  or  NSTDs: 

•  Training  device  JWG. 

•  Manpower  and  personnel  integration  (MANPRINT)  JWG 
(MJWG). 

•  Test  integration  working  group  (TIWG). 

•  System  mission  need  statement  (MNS)  JWG. 

•  System  operational  requirements  document  (ORD)  JWG. 

•  Training  and  support  work  group  (TSWG). 

Of  the  six  JWGs  listed  above,  the  most  important  to  the  training 
developer  is  the  Training  Device  JWG.  Accordingly,  this  process  will  be 
addressed  in  detail  in  this  chapter.  Sufficient  information  will  be 
provided  on  the  other  JWGs  to  familiarize  the  training  developer  with  the 
purpose  of  each  in  order  to  make  a  meaningful  contribution  as  the  need 
arises. 
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JWG  Composition 


Pertinent 
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Related  Pages 


JWG  membership  can  be  comprised  of  any  number  of  personnel  and 
agencies  that  the  propot,  >t  (combat,  materiel,  or  training  developer) 
determines  can  contribute  to  the  development  of  the  designated 
requirements  and  documentation  process. 


AR  70-1 ,  Army  Acquisition  Policy 

AR  350-38,  Training  Device  Policies  and  Management 


Training  Device  Joint  Working  Group  Process,  pg.  7-3 
Other  Joint  Working  Groups,  pg.  7-13 
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Training  Device  Joint  Working  Group  Process 


Introduction 


Purpose 


Process 


The  development  and  acquisition  of  training  devices  requires  the 
coordinated  effort  of  a  number  of  personnel  and  agencies  working 
together  for  a  common  goal.  Each  has  a  specific  area  of  expertise  or 
input  that  supports  development  of  the  most  cost-  and  training-effective 
systems  and  devices. 

JWGs  bring  representatives  from  specified  agencies  together  and 
provide  a  forum  for  direct  communication  that  facilitates  the  coordination 
of  requirements  documentation,  identification  and  assignment  of 
responsibilities  and  action  items,  and  establishment  of  milestones  for 
completing  these  actions. 

During  the  training  device  development  and  acquisition  process,  there 
will  normally  be  at  least  two  JWGs.  The  conduct  of  the  JWGs  for 
NSTDs  and  for  system  TADSS  is  basically  the  same.  Accordingly,  this 
discussion  of  the  JWG  process  will  address  the  process  as  it  relates  to 
NSTDs.  Where  appropriate,  differences  in  the  process  applicable  to 
system  TADSS  will  be  identified.  For  ease  of  identification,  the  word 
"NOTE"  will  precede  an  explanation  of  the  difference  in  the  process. 


The  training  device  JWG  has  three  primary  purposes: 

•  Prepare  requirements  documentation. 

•  Assign  responsibilities  for  action  items. 

•  Establish  milestones  for  completion  of  action  items. 


The  proponent  training  developer  and  the  materiel  developer  (usually 
simulation;  training,  and  instrumentation  command  (STRICOM))  jointly 
chair  the  training  device  JWGs.  Normally,  there  are  two  JWGs 
associated  with  the  development  of  a  training  device.  In  some  cases 
additional  JWGs  may  be  necessary.  The  following  figure  depicts  the 
JWG  process  and  events  that  lead  to  a  coordinated  final  ORD  for 
submission  to  the  approval  authority. 
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Process  (con.) 
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Before  a  JWG  for  an  NSTD  can  be  scheduled  or  conducted,  the  training 
developer  must  provide  sufficient  information  to  the  training  and  materiel 
development  communities  for  the  major  players  to  clearly  understand 
the  requirement.  To  accomplish  this  the  proponent  develops  a 
strawman  ORD  and  concurrently  coordinates  with  ATSC  for  scheduling 
of  JWG  1 .  The  completed  Strawman  ORD  is  forwarded  through  the 
integrating  command  to  ATSC  for  review  and  subsequently  forwarded  to 
JWG  1  members  in  the  read-ahead  package. 

NOTE:  System  TADSS  that  have  been  identified  and 

documented  in  the  system  ORD  do  not  require  a  separate 
MNS  or  ORD.  In  this  case  the  JWG  process  is  initiated 
by  forwarding  the  training  device  requirements  data 
package  to  ATSC  (see  chapter  4). 


•JWG  1  ATSC  in  coordination  with  the  proponent  and  the  materiel  developer 

determines  a  tentative  date  and  prospective  attendees  for  JWG  1 .  All 
prospective  members  are  notified  and  provided  a  read-ahead  package 
that,  as  a  minimum,  consists  of  the  following: 

•  Strawman  ORD  with  applicable  annexes. 
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JWG  1  (con.) 


•  School  point  of  contact  (POC). 

•  Security  clearance  requirements  (if  applicable). 

•  JWG  date,  time,  location,  and  billeting  information. 

•  Chairperson  and  vice  chairperson  designees. 

Invitees  are  requested  to  provide  to  the  proponent  POC  a  list  of 
attendees  and/or  POCs  by  name,  grade,  and  security  clearance  (if 
required)  at  least  one  week  prior  to  the  scheduled  JWG.  Agencies 
unable  to  attend  the  scheduled  JWG  will  provide  comments  containing 
all  information  essential  to  the  developing  ORD  (also  one  week  prior  to 
the  JWG). 

When  the  JWG  has  been  convened,  the  agenda  that  was  provided  to 
the  members  is  the  basis  for  discussions.  The  chairperson  (proponent 
training  developer)  and  vice  chairperson  (materiel  developer)  may 
establish  or  modify  the  agenda  and  procedures  to  meet  JWG  objectives. 
In  any  case,  the  following  are  normally  part  of  the  agenda: 

•  Proponent’s  overview  -  expands  on  the  requirements  information 
provided  in  the  read-ahead  package.  Administrative  details  and 
guidelines  for  conduct  of  the  meeting  are  presented. 

•  Training  effectiveness  analysis  (TEA)  requirements  -  ATSC 
informs  the  proponent  of  the  extent  of  the  study  effort  that  will  be 
required. 

•  Personnel/agency  assignments  for  and  milestones  for  completion 
of- 


System  MANPRINT  management  plan  (SMMP). 

System  training  plan  (STRAP)  (if  applicable). 

Concept  formulation. 

Test  and  evaluation  master  plan  (TEMP). 

Basis  of  issue  plan  (BOIP)  and  qualitative  and 
quantitative  personnel  requirements  information  (QQPRI). 

Reliability,  availability,  and  maintainability  (RAM). 

New  equipment  training  plan  (NETP)  (if  applicable). 

Training  device  strategy. 
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JWG  1  Proponent’s 
Overview 


Draft  ORD 


All  members  of  the  JWG  should  have  a  basic  understanding  of  the 
device  requirement  from  the  read-ahead  package  provided  by  the 
proponent  training  developer.  The  proponent’s  overview  expands  on  the 
read-ahead  and  responds  to  questions  regarding  the  following: 

•  Training  deficiencies  that  led  to  the  determination  that  a  training 
device  is  required. 

•  Constraints  associated  with- 

Device  characteristics. 

Training  environment  in  which  the  device  must  operate. 
Cost. 

Proposed  basis  of  issue  (BOI)  to  support  the  device 
strategy. 

Required  availability  date  for  training. 

RAM. 

Any  other  factors  that  will  impact  on  development  of  the 
draft  ORD. 

•  Procedures  for  conduct  of  the  meeting  and  objectives  to 
be  achieved. 


After  input  from  the  JWG  members  has  been  received  in  all  subject 
areas,  the  group  can  develop  the  draft  ORD.  The  ORD  should  be  as 
detailed  as  possible,  although  it  cannot  be  complete  until  all  actions 
have  been  completed.  The  content  and  format  of  the  ORD  are  found  in 
chapter  3  of  this  procedural  guide.  The  subject  areas  listed  in  the 
proponent’s  overview  provide  the  essential  information  to  develop  the 
basic  document  and  annexes  (except  life  cycle  cost  summary  and 
coordination  annexes,  which  are  completed  after  JWG  2  and  final  ORD 
staffing). 

For  system  TADSS  the  training  device  requirements  data  package  is 
used  to  provide  information  to  the  materiel  developer  for  preparation  of 
the  formal  IPR  package  as  required  by  DOD  5000.2-M  Defense 
Acquisition  Management  Documentation  and  Reports. 


Assign  Action 

Items/Establish 

Milestones 


Comment 


At  this  point  in  the  training  device  development  and  acquisition  process, 
there  are  many  unanswered  questions  regarding  the  design,  cost, 
required  distribution,  supportability,  and  operational  parameters. 
Additional  studies  and  analyses  are  required  to  answer  these  questions 
and  ensure  acquisition  of  a  cost-  and  training-effectiveness  device  that 
addresses  the  training  deficiency.  JWG  members  are  assigned  actions 
to  respond  to  these  questions  prior  to  JWG  2.  These  actions  include 
the  following: 

•  Conduct  of  the  concept  formulation  leading  to  the  best  technical 
approach  (BTA),  which  is  to  be  selected  at  JWG  2. 

•  Conduct  of  MANPRINT-related  studies. 

•  Development  of  the  device  NETP  (if  required). 

•  Submission  of  BCiP  feeder  data  (BOiPFD)/QGPRI. 

•  Development  of  the  BOIP/QQPRI. 

•  Development  of  RAM  data  (to  be  completed  after  selection  of 
BTA). 

•  Input  to  the  TEMP  and  related  test  plans. 

•  Development  of  and/or  revision  of  the  STRAP  (if  required). 

•  Conduct  of  the  TEA. 

Milestones  for  completion  of  each  of  the  action  items  are  established 
and  recorded  in  the  minutes  of  JWG  1 .  The  scheduling  for  JWG  2  is 
dependent  on  completion  of  concept  formulation. 


All  of  the  actions  listed  above  are  phased  developments  conducted 
throughout  the  acquisition  process.  See  appropriate  chapters  for  more 
detail  on  the  accomplishment  of  these  actions. 

NOTE:  Training  developer  responsibilities  for  the  completion  of 

these  actions  for  the  acquisition  of  NSTD  may  differ  from 
those  for  the  acquisition  of  system  TADSS. 
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JWG2 


JWG  2  Agenda 


The  time  between  the  end  of  JWG  1  and  the  start  of  JWG  2  is  used  to 
complete  the  action  items  that  were  assigned  at  JWG  1 .  These  actions 
may  include  update  of  the  STRAP,  TEMP,  and  SMMP  as  well  as  the 
conduct  of  tests  and  studies  and  the  development  of  much  of  the  RAM 
data.  The  level  of  effort  required  for  each  of  these  actions  may  vary 
between  devices. 

JWG  2  is  normally  the  only  time  that  all  members  of  the  JWG 
reconvene.  Intensive  work  by  all  members  occurs  between  the  JWGs  to 
support  the  ongoing  development  of  device  characteristics,  training 
device  strategies,  logistics  support  requirements,  MANPRINT 
requirements,  BOI,  and  other  actions  leading  to  a  complete  and 
accurate  documentation  of  the  requirement.  By  the  time  JWG  2  is 
convened,  these  data  elements  should  be  fairly  solidified.  JWG  2  is 
conducted  much  like  JWG  1  with  the  intent  of  finalizing  actions  and 
establishing  milestones  for  producing  a  final  draft  ORD  for  coordination. 
JWG  2  has  four  primary  purposes: 

•  Select  the  BTA. 

•  Complete/assign  action  items  necessary  for  the  completion  of  the 
final  draft  ORD  documentation  package. 

•  Assign  responsibilities  to  JWG  members  for  those  actions 
remaining  in  the  device  development  cycle. 

•  Establish  milestones  for  completion  of  action  items  or  events. 

The  composition  of  JWG  2  is  the  same  as  the  composition  for  JWG  1 . 
New  members  may  be  added  to  the  JWG  membership  as  required  at 
any  point  in  the  JWG  process. 


As  in  JWG  1 ,  the  agenda  for  JWG  2  is  provided  as  part  of  the  read- 
ahead  package.  The  proponent  training  developer  and  the  materiel 
developer  establish  the  agenda  and  conduct  the  JWG  in  the  most 
efficient  manner  appropriate  for  the  developing  device.  The  following 
items  are  discussed,  and  to  the  extent  possible,  agreed  upon  at  JWG  2: 

•  A  proponent’s  overview,  summarizing  the  actions  and  decisions 
occurring  since  JWG  1. 


Presentation  of  the  technical  approaches  by  the  materiel 
developer  and  the  selection  of  the  BTA  by  the  training  developer. 


JWG  2  Agenda 

(con.) 


Proponent's 

Overview 


Select  Best 
Technical  Approach 
(BTA) 


Milestones  for  completion  of  all  paragraphs  and  annexes  of  the 
ORD  (except  for  the  coordination  annex,  which  is  completed  as  a 
result  of  staffing  actions). 


The  proponent  opens  the  JWG  with  a  brief  discussion  of  the  status  of 
the  developing  ORD  and  a  summary  of  the  actions  occurring  since  JWG 
1 .  Members'  questions  regarding  the  read-ahead  package  are 
answered.  The  intent  of  the  overview  is  to  review  all  actions  related  to 
the  following: 

•  Training  deficiencies  that  led  to  the  determination  of  the  training 
device  requirement. 

•  Training  device  strategy. 

•  BOI  to  support  the  device  strategy. 

•  Constraints  associated  with-- 

Device  characteristics. 

Training  environment. 

-  Cost. 

Required  availability  date. 

RAM. 

Other  factors  that  will  affect  development  of  the  final  ORD 
or  fielding  of  the  device. 

•  Status  of  action  items  from  JWG  1 . 

•  Procedures  for  conduct  of  the  meeting  and  objectives  to  be 
achieved. 


The  materiel  developer  presents  to  the  JWG  members  the  technical 
approaches.  The  training  developer  will  select  the  BTA  based  on  the 
previous  results  of  the  TOD  and  TOA.  Briefing  information  for  each 
alternative  wifi  include  the  following: 

•  A  description  of  the  alternative. 
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Trade-offs  associated  with  the  alternative. 


Select  Best 
Technical  Approach 
(BTA)  (con.)  •  Associated  risks. 

•  Capabilities. 

•  Integrated  logistic  support  (ILS),  including-- 

Administrative  and  logistic  down  time  (ALDT). 

Best  operational  capability  (BOC). 

Minimum  acceptable  value  (MAV)  and  cost  to  meet  stated 
operational  availability. 

•  Environmental  and  ecological  factors. 

•  Health,  safety,  and  human  factors  engineering. 

Once  the  BTA  has  been  selected,  the  materiel  developer  can  begin 
work  on  annex  D  of  the  ORD  (life  cycle  cost  summary).  The  life  cycle 
cost  summary  is  an  action  item  to  be  completed  after  JWG  2  and  prior 
to  staffing  of  the  final  draft  ORD. 


Develop  Final  Draft  After  selection  of  the  BTA,  JWG  members  begin  the  development  of  the 

ORD  final  draft  ORD  and  subsequent  staffing.  Comments  from  staffing  are 

used  to  finalize  the  ORD  for  the  approval  process. 

To  develop  the  final  draft  ORD,  JWG  members  use  all  information 
gained  from  completion  of  the  actions  and  events  between  JWG  1  and 
JWG  2.  All  paragraphs  and  appendices  are  addressed  and  developed 
during  this  process  except  the  coordination  annex,  which  is  developed  at 
the  conclusion  of  staffing. 

There  are  a  number  of  actions  and  events  that  continue  during  the 
training  device  development  process  that  must  be  planned  before  the 
JWG  convenes.  These  actions,  many  of  which  are  continuations  of 
tasks  and  milestones  scheduled  at  JWG  1 ,  include  the  following: 

•  Update  of  the  SMMP  and  conduct  of  MANPRINT-related  studies. 

•  Update  of  the  NETP  (if  it  was  determined  that  new  equipment 
training  will  be  required). 


Finalization  of  and  updates  to  BOIP/QQPRI. 


Develop  Final  Draft 
ORD  (con.) 


Develop  Final  Draft 
ORD  for  Staffing 


Update  to  the  TEMP  and  accomplishment  of  further  technical 
and  operational  testing. 

Update  of  the  STRAP  (if  it  was  determined  that  a  STRAP  would 
be  required). 

Development  of  the  life  cycle  cost  summary. 

Finalization  of  the  RAM  rationale  report. 

Completion  or  update  of  the  TEA  as  required. 


The  majority  of  the  work  to  develop  the  final  draft  ORD  for  staffing  and 
eventual  approval  occurred  during  JWG  2.  The  key  tasks  that  remain  to 
complete  the  process  are  including  information  that  could  not  be 
included  at  the  JWG,  staffing  the  document  for  comment,  and  finalizing 
the  document  for  the  approval  process.  The  training  developer  prepares 
the  final  draft  ORD  for  staffing.  This  document  is  staffed  internally  at  the 
proponent  school  then  forwarded  through  the  proponent’s  integrating 
command  to  ATSC  for  continued  staffing.  (Additional  information 
regarding  the  staffing  and  coordination  of  the  ORD  is  in  chapter  3.) 
Staffing  actions  include  the  following: 

•  Deputy  Chiefs  of  Staff  elements  at  HQ  TRADOC. 

•  Other  MACOMs  as  appropriate. 

•  Other  services  as  appropriate. 

•  Office  of  the  Chief,  Army  Reserve  (OCAR)/National  Guard 
Bureau  (NGB). 

•  Director  of  Information  Systems  Command. 

At  the  completion  of  the  staffing  process,  ATSC  reviews  and 
consolidates  comments  and  forwards  them  to  the  proponent  school. 

The  proponent  incorporates  appropriate  comments  in  the  ORD  and 
records  actions  taken  on  comments  in  the  coordination  annex. 

The  proponent  school  forwards  the  completed  document  under  signature 
of  the  School  Commandant  to  ATSC  for  review  by  the  Training  Device 
Requirement  Review  Committee  (TDRRC).  Members  of  the  JWG  may 
be  called  upon  for  additional  data  or  updates  for  continuing  events  and 
actions  during  the  remainder  of  the  life  cycle  for  the  developing  training 
device. 
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Other  Joint  Working  Groups 


Introduction 


Types  of  JWGs 


Working  Group 
Composition 


MANPRINT  JWG 


The  JWG  process  encompasses  a  number  of  different  types  of  JWGs 
that  are  available  for  the  training  developer  and  combat  developer  to 
use  in  the  materiel  acquisition  program.  The  first  portion  of  this  chapter 
outlined  the  JWGs  that  specifically  apply  to  training  devices  or  materiel 
systems  with  emphasis  on  the  training  developer’s  interaction.  The 
focus  of  this  information  map  is  the  JWGs  that  are  primarily  the 
responsibility  of  the  combat  developer.  These  JWGs  do  however 
require  training  developer  attendance  and/or  input. 


Five  types  of  JWGs  are  discussed  in  this  information  map: 

•  MANPRINT  joint  working  group  (MJWG). 

•  TIWG. 

•  System  MNS  JWG. 

•  System  ORD  JWG. 

•  TSWG. 


JWG  membership  can  be  comprised  of  any  number  of  personnel  and 
agencies  that  the  JWG  proponent  (combat,  materiel,  or  training 
developer)  determines  appropriate  to  the  development  of  the 
requirements  document  or  specific  subject  areas  for  the  designated 


JWG. 


The  proponent  combat  developer  chairs  the  MJWG.  It  is  convened 
early  in  the  system  development  process,  as  soon  as  possible  after  the 
need  for  a  new  or  improved  materiel  system  has  been  identified.  MJWG 
scheduling  normally  occurs  before  milestone  0  (MNS  approval)  in  the 
acquisition  process.  The  training  developer  should  attend  this  JWG  to 
ensure  that  all  MANPRINT  requirements  for  training  subsystems,  to 
include  training  devices,  are  being  considered  or  identified  to  the 
proponent  combat  developer.  Of  particular  importance  at  this  point  are 
the  SMMP  and  the  ECA  input  considerations.  The  MJWG  has  three 
main  purposes: 
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MANPRINT  JWG 
(con.) 


Test  Integration 
Working  Group 
(TIWG) 


Identify  and  manage  MANPRINT  issues  throughout  the  materiel 
acquisition  process. 

Provide  oversight  to  ensure  that  the  MANPRINT  process  is 
carried  out  and  that  the  products  are  meaningful. 

Determine  what  MANPRINT  analyses  will  be  required  for  the 
proposed  system  or  training  subsystem  development. 


The  materiel  developer  chairs  the  TIWG.  The  proponent  is  responsible 
to  integrate/combine  tests  to  develop  the  most  efficient  and  cost- 
effective  test  program.  This  is  accomplished  through  the  TIWG.  The 
TIWG  is  a  working  group  designed  to  facilitate  the  integration  of  test 
requirements  through  close  coordination  between  the  materiel 
developer,  training  developer,  combat  developer,  and  operational  testers 
with  a  purpose  to  minimize  test  development  time  and  cost  and  preclude 
duplication  between  developmental  and  operational  testing.  The  TIWG 
develops  a  TEMP  that  covers  all  T&E  actions  through  the 
production/deployment  phase  of  the  acquisition  process. 

The  TIWG  has  four  primary  purposes: 

•  Assist  the  materiel  developer  in  the  preparation  of  the  TEMP. 

•  Monitor  the  test  program’s  progress. 

•  Update  the  TEMP  as  required. 

•  Develop  and  finalize  critical  operational  issues  and  criterias 
(COICs). 

Test  and  evaluation  (T&E)  are  integral  parts  of  the  materiel  acquisition 
process.  T&E  ultimately  provides  the  data  to  answer  the  basic  concern 
of  whether  the  system/device  will  perform  as  required:  Can  the  soldier 
use  it,  is  it  training  effective,  and  is  it  affordable?  T&E  is  conducted  to 
assist  decision  makers  in  reducing  acquisition  risks  by- 

•  Validating  attainment  of  technical  performance  specifications, 
objectives,  and  supportability. 

•  Examining  materiel  defects. 
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Test  Integration 
Working  Group 
(T1WG)  (con.) 


•  Assessing  training  and  operational  effectiveness,  suitability,  and 
readiness. 

•  Determining  training  requirements,  compatibility,  and 
interoperability  as  required. 

U.S.  Army  policy  requires  integrated  testing  where  feasible  and  the  use 
of  all  available  data  (for  example,  contractor,  other  services,  allies)  for 
evaluation  purposes.  These  considerations  are  addressed  during  TIWG 
planning. 


System  Mission 
Need  Statement 
(MNS)  Joint 
Working  Group 
(JWG) 


The  proponent  combat  developer  for  the  system  MNS  convenes  and 
chairs  the  MNS  JWG.  The  intent  of  the  MNS  JWG  is  to  obtain  input 
from  major  players  in  the  requirements  documentation  process  to 
produce  the  system  MNS.  Training  developer  attendance  at  this  JWG  is 
essential  to  ensure  that  the  proposed  training  strategy,  including 
probable  requirements  for  embedded  training  capabilities  and  training 
devices,  is  identified  in  the  MNS.  These  actions  permit  programming  of 
funds  to  support  concept  formulation  and  the  eventual  research  and 
development  (R&D)  and  procurement  of  the  system  and  training  support 
items.  (See  chapter  4  for  additional  Information.) 

The  development  of  the  training  strategy  and  the  recognition  of  probable 
system  TADSS  requirements  are  supported  by  the  early  comparability 
analysis  (ECA).  If  a  formal  ECA  is  not  conducted,  the  training  developer 
should  use  the  ECA  methodology  to  arrive  at  an  initial  training  strategy 
and  proposed  TADSS  requirements.  For  detailed  information  regarding 
this  process,  see  the  Training  Developers'  Procedural  Guide  for  Training 
Device  Strategies. 


System  Operational 
Requirements 
Document  (ORD) 
Joint  Working 
Group  (JWG) 


The  proponent  combat  developer  for  the  system  ORD  convenes  and 
chairs  the  ORD  JWG.  It  takes  place  after  staffing  of  the  draft  system 
ORD.  The  purpose  of  the  ORD  JWG  is  to  resolve  differences  arising 
from  the  staffing,  to  incorporate  staffing  comments,  and  to  produce  a 
final  system  ORD.  Training  developer  input  to  the  ORD  JWG  updates 
tiie  training  strategy  and  the  need  for  training  devices  and  embedded 
training  capabilities.  (See  chapter  4  for  additional  information.) 
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System  Operational 
Requirements 
Document  (ORD) 
Joint  Working 
Group  (JWG)  (con.) 


Training  Support 
Working  Group 
(TSWG) 


Comment 


Pertinent 
Regulations  and 
Publications 


The  ORD  does  not  undergo  a  second  staffing  after  completion  of  the 
ORD  JWG;  accordingly,  the  training  developer  should  be  prepared  to 
present  the  combat  developer  with  an  updated  training  support 
requirements  (TSR)  annex  (annex  C)  based  on  comments  from  staffing 
and  training  decisions  derived  from  the  continuing  training  analyses  that 
have  occurred  since  the  draft  was  developed  and  staffed  with  the 
system  ORD. 


The  materiel  developer  (designated  major  subordinate  command  (MSC) 
of  AMC)  having  responsibility  for  development  of  the  emerging  system 
convenes  and  chairs  the  TSWG.  The  TSWG  has  three  primary 
purposes: 

•  Coordinate  or  resolve  issues  for  individual  NETPs. 

•  Approve  NETPs. 

•  Develop  the  consolidated  NETP  (CNETP). 

The  MSC  consolidates  and  publishes  NETPs  as  CNETPs.  Individual 
TRADOC  proponent  training  developers  do  not  normally  attend  the 
TSWG;  however,  they  are  represented  by  the  Systems  Training 
Integration  Division  (ST1D),  Training  Development  and  Analysis 
Directorate  (TDAD)  at  HQ  TRADOC.  The  proponent  training  developer 
may  be  required  to  provide  input  for  the  NETP  prior  to  the  TSWG  (see 
chapter  5). 


Training  developer  input  to  all  JWGs  and  related  documentation 
discussed  here  is  obtained  from  the  STRAP  and  reformatted,  as 
required,  for  requirements  documentation  purposes.  If  the  training 
developer  has  developed  and  updated  the  STRAP,  the  required 
information  is  readily  available  for  these  JWGs,  which  ensures  that 
training  support  requirements  for  the  emerging  system  are  considered 
for  development,  funding,  and  acquisition 


AR  350-35,  New  Equipment  Training 

AR  350-38,  Training  Device  Policies  and  Management 

AR  602-2,  Manpower  and  Personnel  Integration  (MANPRINT)  in  the 
Materiel  Acquisition  Process 
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CHAPTER  8 


VALIDATION/PRIORITIZATION  AND 
REVIEW/APPROVAL  PROCESS 


Validation/Prioritization  and 
Review/Approval  Processes 

Overview 


Introduction 


Throughout  the  development  cycle  of  a  training  device,  priorities  must 
be  assigned  and  decisions  must  be  made  regarding  program  direction 
and  continuation.  The  joint  working  group  (JWG)  process  (addressed  in 
chapter  7)  provides  a  forum  for  the  majority  of  the  preliminary  decisions 
pertaining  to  training  device  program  direction.  However,  the  JWG 
process  does  not  provide  high-level  decision  makers  the  opportunity  to 
observe  program  status  and  to  provide  direction.  This  chapter  provides 
background  on  the  processes  used  by  combat  developers,  training 
developers,  materiel  developers,  and  decision  makers  to  prioritize 
devices,  determine  program  status,  and  provide  development  direction 
for  system  TADSS  and  NSTDs.  Ateas  covered  include  the  following: 

•  Validation/Prioritization-- 

Combined  arms  training  strategy  (CATS)  prioritization. 

Training  mission  area  (TMA)  prioritization  process. 

Long-range  research,  development,  and 
acquisition  plan  (LRRDAP)  prioritization  process. 

•  Review/Approval- 

Requirements  review  committee  (RRC). 

Training  device  requirements  review  committee  (TDRRC). 
In-process  review  (I PR). 

Some  of  these  processes  and  committees  have  application  to  both 
system  TADSS  and  NSTDs  while  others  apply  only  to  one  or  the  other, 
line  different  applications  will  be  identified  and  explained  as  appropriate. 
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Process 


To  understand  the  process  of  prioritization  and  review  of  training  device 
acquisition  programs,  each  of  the  processes  and  committees  listed 
above  must  be  considered  as  a  part  of  the  overall  process.  As  the 
following  figure  shows,  the  process  begins  with  a  prioritization  of  the 
device  within  the  overall  concept  of  the  CATS.  This  strategy  includes 
TADSS  and  all  the  training  resources  required  to  train  the  U.S.  Army 
now  and  those  required  for  future  training. 


If  TADSS  are  required  to  support  training  for  a  new  system,  then  the 
device  acquisition  program  will  follow  the  system  documentation 
process,  and  the  combat  developer’s  RRC  will  review  the  requirements 
prior  to  approval.  Training  developer  representation  at  this  committee  is 
provided  by  the  System  Training  Integration  Division  (STID),  Training 
Developments  and  Analysis  Directorate  (TDAD)  at  HQ  TRADOC.  The 
TDRRC  reviews  training  device  requirements  data  packages  for  each 
individual  system  device. 

If  the  requirement  is  for  an  NSTD,  then  the  process  follows  the  NSTD 
requirements  documentation  process  and  is  reviewed  prior  to  approval 
by  the  TDRRC. 

In  either  case  ATSC  periodically  reviews  the  acquisition  program 
throughout  its  development  cycle  at  HQ  TRADOC  to  obtain  a  TRADOC 
position  on  program  direction  prior  to  any  I  PR  conducted  by  the  materiel 
developer.  Milestone  decisions  throughout  the  program  are  made  at  the 
IPRs. 
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CATS  Prioritization 


Training  device  requirements  are  considered  validated  when  they  are 
included  in  an  approved  CATS.  Prioritization  of  these  validated 
requirements  is  accomplished  in  one  of  two  ways  dependent  on  the 
category  of  device  (nonsystem  or  system).  NSTDs  are  prioritized  under 
the  TMA  prioritization  process  while  STDs  are  prioritized  along  with  the 
system  they  support  under  the  LRRDAP  prioritization  process. 

•  The  TMA  prioritization  process  establishes  priorities  for  all 
NSTDs  based  on  their  criticality  of  need.  Each  NSTD 
requirement  is  evaluated  against  all  other  NSTD  requirements  to 
form  a  notional  1  -N  prioritization  listing. 

•  The  LRRDAP  prioritization  process  establishes  priorities  for 
materiel  system  requirements  STDs  are  included  in  the 
acquisition  programs  of  the  materiel  systems  that  they  support 
and  are  prioritized  with  the  systems. 


The  Deputy  Chief  of  Staff  for  Combat  Developments  (DCSCD)  convenes 
the  RRC  at  HQ  TRADOC  to  review  all  aspects  of  the  final  system  ORD 
prior  to  recommending  approval  by  the  designated  authority.  The 
proponent  training  developer  is  normally  represented  at  the  RRC  by  the 
STID  representative.  Training  developer  input  is  essential  at  this  review, 
since  this  is  the  last  time  the  training  developer  is  able  to  influence 
requirements  prior  to  the  development  of  a  request  for  proposal  (RFP) 
for  the  system  and  its  training  subsystem. 


TDRRC  The  TDRRC  is  chaired  by  the  Director,  Devices  Management 

Directorate  (DMD),  ATSC  with  members  from  TRADOC  and  observers 
from  STRICOM.  The  TDRRC  is  convened  to  review  and  recommend 
approval  of  requirements  for  new  or  modified  training  devices  as 
required. 


The  materiel  developer  conducts  IPRs  throughout  the  system’s  or 
device’s  development  cycle.  The  combat  developer,  the  training 
developer,  and  others  having  input  to  the  program  attend  the  IPRs.  An 
IPR  is  conducted  before  each  decision  point  in  the  acquisition  process 
and  any  time  that  major  changes  occur  in  the  program.  Concurrence 
and/or  comments  from  all  members  of  the  IPR  concerning  program 
status  and  direction  are  consolidated  and  forwarded  to  appropriate 
decision  makers  for  review/approval  as  appropriate. 
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Pertinent 
Regulations  and 
Publications 


Related  Pages 


AR  70-1 ,  Army  Acquisition  Policy 

HQTRADOC  Memorandum,  Subject:  Policy  for  TRADOC  Materiel 
Documentation  Review  and  Approval 


Combined  Arms  Training  Strategy,  pg.  8-5 
Requirements  Review  Committee,  pg.  8-8 
Training  Device  Requirements  Review  Committee,  pg.  8-11 
In-Process  Review,  pg.  8-14 
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Combined  Arms  Training  Strategy 


Introduction 


TMA  Prioritization 
Process 


CATS  is  the  overarching  training  strategy  for  the  U.S.  Army.  It  identifies 
training  products,  materiel,  and  resources  required  for  current  and  future 
training.  Integration  of  training  devices  into  approved  CATS  serves  as  a 
validation  of  device  requirements  and  permits  the  development  of 
requirements  documentation.  CATS  is  an  integral  part  of  the  Enhanced 
Concept-Based  Requirements  System  (ECBRS).  ECBRS  consists  of  in- 
depth  analyses  of  the  current  and  projected  threat  in  order  to  identify 
and  resolve  war-fighting  capability  issues.  Products  emanating  from  the 
ECBRS  are  incorporated  into  planning  documents  used  to  define  and 
resource  programs  in  the  domains  of  doctrine,  training,  leader 
development,  organizations,  materiel,  and  soldier  (DTLOMS). 

Two  products  of  the  ECBRS  that  are  critical  to  the  prioritization  and 
resourcing  of  training  devices  are  the  CATS  and  the  LRRDAP.  The 
CATS  and  the  LRRDAP  provide  the  framework  for  the  prioritization  of 
training  devices  competing  for  limited  resources  placed  again  acquisition 
programs. 


Since  the  CATS  is  the  capstone  document  of  the  TMA  of  the  ECBRS, 
NSTDs  prioritized  under  CATS  are  said  to  be  prioritized  under  the  TMA 
prioritization  process.  This  process  establishes  priorities  for  all  NSTDs 
based  on  their  criticality  of  need.  The  process  is  comprised  of  a  number 
of  procedures  and  decision  points  that  culminate  in  a  prioritized  1 
through  N  (1  -N)  list  of  NSTDs.  The  following  figure  shows  the  events 
that  take  place  each  even-  numbered  calendar  year  in  this  prioritization 
process.  The  objective  is  to  produce  in  September  of  each  even- 
numbered  calendar  year  a  prioritized  training  resource  list  that  enables 
TRADOC  and  HQDA  to  integrate  NSTD  funding  requirements  into  the 
Program  Objective  Memorandum  (POM). 


The  process  begins  when  combined  arms  command-training  (CAC-T) 
drafts  a  1-N  notional  list  prioritizing  NSTDs  from  proponents’  input.  The 
notional  list  is  provided  to  the  general  officer  working  group  (GOWG)  for 
review  and  revision  as  required.  CAC-T  incorporates 
comments/revisions  from  the  GOWG  into  a  draft  prioritization  list  and 
coordinates  this  list  with  MACOMs. 

The  ATSC  and  HQ  DA  jointly  chair  a  panel  consisting  of  representatives 
from  the  MACOMs  to  further  refine  the  draft  prioritization  list  of  the 
NSTDs.  The  refined  list  derived  from  this  panel  is  coordinated  with  the 
Commanders  in  Chief  (CINCs)  of  the  MACOMs,  and  CAC-T  prepares  a 
final  list  that  is  presented  to  the  CG  TRADOC  for  approval.  Upon 
commanding  general  (CG)  TRADOC  approval,  the  list  is  forwarded  to 
DCSOPS  for  final  approval  and  incorporation  into  the  POM  and  long- 
range  plans. 
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LRRDAP 

Prioritization 

Process 


Comment 


Pertinent 
Regulations  and 
Publications 


Related  Pages 


The  LRRDAP  is  the  long-range  planning  document  for  research, 
development,  and  acquisition  of  materiel  systems  identified  as 
requirements  under  the  ECBRS.  The  LRRDAP  prioritization  process 
establishes  priorities  for  materiel  system  requirements.  STDs  are 
included  in  the  acquisition  programs  of  the  materiel  systems  that  they 
support  and  are  prioritized  with  the  systems.  Requirements  for 
prioritization  of  materiel  systems  for  the  LRRDAP  are  the  responsibility 
of  the  proponent  combat  developer.  Input  to  the  combat  developer  by 
the  proponent  training  developer  is  required  to  ensure  training 
subsystems,  including  devices,  are  identified  and  included  as  part  of 
system  acquisition  programs. 


Additional  details  and  explanations  for  this  process  are  contained  in 
TRADOC  Regulation  350-40,  The  Combined  Arms  Training  Strategy. 


AR  70-1 ,  Army  Acquisition  Policy 

AR  350-38,  Training  Device  Policies  and  Management 

TRADOC  Reg  350-40,  The  Combined  Arms  Training  Strategy 


Nonsystem  Training  Device  Mission  Need  Statement,  pg.  3-4 

Nonsystem  Training  Device  Operational  Requirements  Document, 

pg.  3-9 

System  Mission  Need  Statement,  pg.  4-4 

System  Operational  Requirements  Document,  pg.  4-9 


8-7 


Requirements  Review  Committee 


Introduction 


Process 


Membership 


The  RRC  serves  as  the  user  representative  for  review,  validation,  and 
processing  of  requirements  documentation  for  new  systems.  The 
committee  ensures  documents  are  complete  and  that  they  clearly  state 
the  required  essential  characteristics  of  the  system  in  sufficient  detail  to 
allow  the  materiel  developer  to  proceed  with  an  RFP  to  industry  for 
design  and  development  of  the  system.  Training  developer 
representation  to  the  RRC  is  provided  by  the  STID,  TDAD  of  the  Deputy 
Chief  of  Staff  for  Training  (DCST)  at  HQ  TRADOC  to  ensure  training 
subsystem  requirements,  including  testing,  are  addressed  in  the 
requirements  document. 


When  the  proponent  combat  developer  has  completed  the  system 
operational  requirements  document  (ORD)  package,  it  is  forwarded  to 
the  DCSCD  at  HQ  TRADOC  for  final  review  prior  to  being  sent  to  the 
approval  authority.  The  DCSCD  coordinates  the  documentation  with 
appropriate  staff  elements  and  schedules  the  RRC.  The  RRC  is  the 
committee  that  conducts  this  review.  The  RRC  members  conduct  a  line- 
by-line  review.  After  this  review  the  committee  either  recommends 
approval  or  returns  the  documentation  to  the  proponent  school  for 
revision  or  with  a  disapproval  and  accompanying  rationale. 


The  RRC  is  normally  chaired  by  the  Director  of  the  Systems,  Priorities, 
and  Integration  Directorate,  DCSCD,  HQ  TRADOC  and  consists  of  the 
following  permanent  members: 

•  Scientific  advisor  (for  major  systems  only). 

•  Director,  Combat  Service  Support  Directorate. 

•  Director,  Combat  Requirements  Directorate. 

•  Director,  Plans  Directorate. 

•  Director,  Training  Development  and  Analysis. 

•  Director,  Requirements  and  Programs  Directorate. 

•  Director,  Systems,  Priorities,  and  Integration  Directorate  (chair). 
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Membership  (con.) 


Purpose 


The  membership  of  the  RRC  may  be  extended  to  include  other 
TRADOC  directorates  or  other  agencies  as  required  for  the  review  of 
documentation  on  specific  systems.  The  Director,  STID  or  a  designated 
representative  normally  represents  the  training  developer  at  RRCs. 


The  RRC  reviews  each  system  ORD  to  ensure  the  following: 

•  it  is  supported  by  a  valid  need  that  cannot  be  solved  by  changes 
in  doctrine,  training,  leader  development,  or  organization. 

•  The  system's  operational  and  essential  characteristics  are 
realistic,  are  based  on  operational  needs,  and  do  not  contain 
specifics  that  actually  belong  in  the  RFP. 

•  The  documentation  has  been  prepared  and  coordinated  under 
current  policy  and  guidance. 

•  The  document  is  clear  and  concise  (free  of  jargon  and  technical 
statements  that  are  hard  to  understand). 

•  The  training  subsystem  is  addressed  sufficiently  to  permit  the 
identification  of  funding  for  training  device  concept  formulation 
and  eventual  procurement. 

After  review  of  the  requirements  document,  the  RRC  takes  one  of  the 

following  actions: 

•  Forwards  the  document  through  the  DCSCD  to  the  TRADOC 
approval  authority. 

•  Returns  the  document  to  the  proponent  school  for  incorporation 
of  RRC-directed  changes. 

•  Disapproves  the  document  and  returns  it  to  the  proponent  school 
with  rationale  for  the  disapproval. 
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Comment 


Pertinent 
Regulations  and 
Publications 


Related  Pages 


Since  the  combat  developer  at  the  proponent  school  has  the  lead  for 
development  of  the  ORD  and  for  preparation  of  the  document  for  RRC 
review,  it  is  essential  for  the  training  developer  to  work  closely  with  the 
combat  developer  to  ensure  that  all  training  requirements  are 
incorporated  in  the  document  prior  to  the  RRC.  While  approval  of  the 
system  ORD  constitutes  the  approval  of  system  TADSS  included  in  the 
document,  the  TDRRC  will  further  review  associated  training  device 
requirements  documentation. 


AR  70-1,  Army  Acquisition  Policy 


System  Operational  Requirements  Document,  pg.  4-9 
Annex  C,  Training  Support  Requirements,  pg.  4-20 
Training  Device  Requirements  Review  Committee,  pg.  8-11 
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Training  Device  Requirements  Review  Committee 


Introduction 


Process 


Membership 


The  TDRRC  serves  as  the  user  representative  for  review,  validation, 
and  processing  of  all  training  device  requirement  documents.  The 
committee  ensures  that  documents  are  complete  and  that  they  clearly 
state  the  type  of  device  the  U.S.  Army  needs  to  support  training  and 
enhance  combat  proficiency.  For  NSTDs  the  committee  reviews  the 
completed  ORD  package.  For  system  TADSS  the  TDRRC  reviews  the 
final  training  device  requirements  data  package. 


The  TDRRC  constitutes  the  final  reviewing  authority  for  all  training 
device  requirements  documentation. 

Requirements  documents  ready  for  approval  are  forwarded  to  the 
Director,  DMD  for  review  and  processing. 

The  Operations  Division,  DMD  conducts  initial  evaluation,  ensures 
accuracy/completeness,  and  schedules  the  document  for  presentation  at 
the  next  committee  meeting. 

The  committee  secretary  schedules  meetings,  notifies  participants,  and 
provides  documents  for  review  not  later  than  10  days  prior  to  the 
meeting.  A  telephone  poll  may  be  conducted  in  lieu  of  a  formal 
meeting. 

TDRRC  provides  comments  and  recommendations  during  formal 
committee  sessions.  Concurrence/nonconcurrence  for  each 
requirements  document  is  provided  at  the  end  of  committee  action. 

Resolution  of  nonconcurrence  is  the  responsibility  of  the  DMD  action 
officer. 


The  Director,  DMD,  ATSC  serves  as  the  permanent  chairperson  of  the 
TDRRC.  Permanent  committee  membership  consists  of  representatives 
from  the  following  organizations: 
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Membership  (con.) 


Voting 


Nonvotinq 


Objectives 


Other 

Considerations 


CASCOM 

CAC 

DMD  ATSC,  HQ  TRADOC 
DCSCD,  HQ  TRADOC 
RTS  ATSC 


Materiel  developer 
Representative,  proponent  school 
DMD  program  manager 
Secretary,  ATSC  Operations 


During  the  review  of  proposed  training  device  requirements  documents, 
committee  members  apply  best  military  judgment  to  ensure  the  following 
major  objectives,  where  applicable,  have  been  met: 

•  Document  complies  with  regulatory  requirements  and  is 
complete. 

•  Adequate  relationship  exists  between  the  statement  of  need,  the 
threat,  operational  and  training  deficiency,  and  the  essential 
characteristics  of  the  proposed  device. 

•  Documentation  clearly  reflects  how  a  training  device  fits  into  the 
overall  training  strategy.  Elements  considered  include  but  are 
not  limited  to  type  unit,  estimated  number  of  personnel  to  use  or 
support  the  device,  and  ammunition  trade-off  (if  applicable). 


Key  considerations  also  covered  in  the  TDRRC  review  are  the  following: 

•  Task  list. 

•  Health  hazard  considerations. 

•  Human  engineering  and  safety. 

•  Transportability. 

•  Operational  environmental  considerations. 

•  Storage  and  maintenance. 

•  Performance  characteristics. 

•  Other  service  application. 

•  Training  strategy. 
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Other 

Considerations 

(con.) 


Required  Annexes 
snd  Attachments 


Pertinent 
Regulations  and 
Publications 


Related  Pages 


•  Testing  milestones. 

•  Cost  assessment. 

•  Major  Army  command  (MACOM)  requirements. 

•  Degree  of  risk. 

•  Prediction  of  training/cost  effectiveness. 

•  Reliability,  availability.and  maintainability  (RAM)  data. 


The  TDRRC  ensures  the  following  annexes/attachments,  as  appropriate, 
have  been  received  and/or  are  available: 

•  Rationale  annex. 

•  Coordination  annex. 

•  Training  device  strategy. 

•  Executive  summary  of  the  training  effectiveness  analysis  (TEA). 

•  RAM  rationale  report/executive  summary  (if  available). 

•  Basis  of  issue  plan/qualitative  and  quantitative  personnel 

requirements  information  (BOIP/QQPRI)  (if  completed). 


AR  70-1 ,  Army  Acquisition  Policy 

AR-350-38,  Training  Device  Policies  and  Management 


Nonsystem  Training  Device  Operational  Requirements  Document, 
pg.  3-9 

System  Operational  Requirements  Document,  pg.  4-9 
Training  Device  Requirements  Data  Package,  pg.  4-26 
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In-Process  Review 


Introduction 


Process 


Within  the  materiel  acquisition  process,  all  systems  or  devices  (except 
those  being  developed  under  the  Designated  Acquisition  Program 
(DAP))  are  reviewed  throughout  the  development  cycle  under  the  IPR 
program. 

The  materiel  developer  conducts  an  IPR  at  the  AMC  major  subordinate 
command  (MSC)  level.  The  AMC  commander  and  the  TRADOC 
commander  normally  exercise  the  joint  AMC/TRADOC  decision 
authority. 


Prior  to  an  IPR,  the  materiel  developer  develops  the  IPR  package  and 
coordinates  it  with  the  IPR  membership.  Upon  receipt  of  the  IPR 
package  for  a  new  system  acquisition  the  TRADOC  system  staff  officer 
prepares  a  recommended  TRADOC  IPR  position.  This  position  is 
coordinated  with  the  appropriate  staff  agencies  for  concurrence.  If 
differences  cannot  be  resolved  by  the  TRASSO  through  this  staffing 
process  then  a  recommended  position  with  the  unresolved  differences 
underscored,  will  be  submitted  to  the  Commanding  General  (CG) 
TRADOC  for  a  decision.  A  TRADOC  IPR  position  is  obtained  for  all 
materiel  acquisition  programs.  The  training  developer  should  provide 
input  to  the  combat  developer  regarding  the  training  subsystem  for 
system  positions.  ATSC  performs  as  the  TRASSO  for  NSTD’s. 

The  information  in  the  IPR  package  is  derived  from  the  documentation 
developed  to  support  the  system  or  training  device  acquisition  program. 
Many  of  these  documents  are  described  in  this  procedural  guide. 

Others  are  peculiar  to  the  materiel  development  community.  A  complete 
list  of  required  documentation  and  formats  to  support  an  IPR  can  be 
found  in  the  DOD  5000  series  directives  and  instructions. 

After  coordination  of  the  IPR  package  (and  concurrence  of  all  members 
if  possible),  the  materiel  developer  schedules  the  IPR  to  present 
recommendations  to  the  decision  authority  on  program  direction.  If  the 
TRADOC  position,  differs  from  the  recommendations  of  the  materiel 
developer,  the  TRADOC  representative  will  defend  the  position  at  the 
IPR.  The  TRASSO  represents  TRADOC  at  IPRs  for  developing 
systems.  ATSC  is  TRADOC ’s  representative  at  NSTD  IPRs. 
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IPR  Participants 


IPR  participants  are  designated  as  members  or  observers.  For  NSTD 
development,  iPR  composition  is  as  follows: 


Purpoae 


Voting  members  are-- 

Materiel  developer  (chair). 

TRADOC. 

Army  Materiel  Support  Analysis  Activity  (AMSAA). 
Operational  Test  and  Evaluation  Command  (OPTEC). 
Observers,  identified  and  invited  by  the  IPR  chair,  include- 
HQDA  representatives. 

Funding  agencies. 

Manpower  and  personnel  integration  (MANPRINT) 
participants. 

Others  involved  in  the  device  development  process. 


The  purpose  of  the  IPR  is  to  make  decisions  relevant  to  the  acquisition, 

testing  or  type  classification  of  an  item  of  materiel  under  development  or 

procurement. 

The  following  are  major  considerations  at  an  IPR: 

•  What  is  the  status  of  the  program  as  opposed  to  what  it  should 
be? 

•  Where  is  the  program  going,  and  how  does  the  program 
executive  officer/project  manager  (PEO/PM)  propose  to  get 
there? 

•  What  risks  exist  in  the  program,  and  how  does  the  PEO/PM 
intend  to  identify  and  close  those  risks? 

•  Is  the  PEO's/PM's  proposed  approach  affordable? 
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Types  of  IPRs  and 
Frequency 


Required 

Information 


IPRs  are  normally  conducted  pricr  to  each  decision  point  in  the 
acquisition  process  and  at  any  time  during  the  system’s  or  device’s 
development  cycle  when  significant  changes  occur  in  the  program.  The 
materiel  developer  and  combat/training  developer  determine  whether  a 
formal  or  informal  IPR  is  required. 

•  Formal  IPRs  are  normally  conducted  by  conference.  A 
conference  is  not  required  when  all  members  unconditionally 
concur  with  the  materiel  developer’s  course  of  action  as 
documented  in  IPR  supporting  documents.  Written  statements  of 
unconditional  concurrence  must  accompany  transmittal  of  the 
document  to  the  approval  authority. 

•  The  materiel  developer  may  convene  informal  IPRs  as  required 
or  when  requested  by  a  member.  The  IPR  is  used  to  review 
program  status  and  determine  appropriate  courses  of  action 
when  a  formal  decision  is  not  required. 

•  Special  IPRs  may  be  directed  as  required  for  major  decisions 
other  than  preprogrammed  or  planned  milestone  documentation. 
These  IPRs  require  the  same  documentation  and  concurrence 
procedure  as  the  formal  IPR. 


As  with  almost  everything  in  acquisition  programs,  the  scope  of  the 

required  information  is  tailored  depending  on  the  specific  program. 

Information  in  the  following  areas  is  required  for  IPRs  at  milestone 

decision  reviews: 

•  Decision  requested. 

•  Program  execution  status  (developmental  efforts  and  financial 

management). 

•  Threat  highlights  and  existing  system  shortfalls  (for  system 
acquisition  programs)  or  training  shortfalls  (for  NSTD  acquisition 
programs). 

•  Alternatives  assessed  and  results. 

•  Most  promising  alternative  and  rationale. 

•  Acquisition  strategy  (including  test  and  evaluation  planning, 
contracting  approach,  and  cooperative  opportunities). 
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Required 
Information  (con.) 


IPR  Results 


Pertinent 
Regulations  and 
Publications 


•  Cost  drivers  and  major  trade-offs. 

•  Risk  assessment  and  plans  to  reduce  or  eliminate  risk. 

•  Affordability  of  selective  alternative  (funding  and  manpower). 

•  Recommendations. 

Some  of  these  areas  are  of  more  importance  at  different  times  within  the 
program.  This  is  why  tailoring  of  the  IPR  is  not  only  authorized  but 
desired. 


Documentation  and  approval  of  IPR  actions  normally  occur  as  follows: 

•  IPR  deliberations  are  recorded  in  the  minutes  and  prepared  by 
the  chair.  All  members  must  sign  the  minutes  before  the  results 
are  forwarded  for  approval.  The  minutes  will  include,  at  a 
minimum-- 

IPR  conclusions  and  recommendations. 

Member  agency  positions. 

Special  input  as  required. 

•  Formal  and  special  IPR  results  are  documented  and  forwarded 
for  approval  within  two  working  days  of  IPR  conclusion. 

•  Approval  authority  announces  decisions  to  all  IPR  participants 
within  ten  working  days. 

•  The  IPR  chair  distributes  the  approved  results  to  all  participants. 


DGDI  5000.2,  Defense  Acquisition  Management  Policies  and 
Procedures 

AR  70-1 ,  Army  Acquisition  Policy 
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MODIFICATION  MANAGEMENT 


Modification  Management 


Introduction 


Objectives 


Reasons  for  MM 


For  more  than  20  years,  the  U.S.  Army  product  improvement  programs 
(PIPs)  were  submitted  by  the  system  manager  to  HQDA  for  approval, 
and  engineering  change  proposals  (ECPs)  were  managed  in  a 
completely  separate  system.  In  an  effort  to  bring  system  changes  under 
one  process,  the  modification  management  (MM)  program  was 
developed.  MM  encompasses  all  hardware,  firmware,  and  software 
changes  to  type  classified  materiel.  Class  II  ECPs  (those  that  do  not 
change  the  form  or  function  of  the  item)  are  not  under  the  MM  process. 


The  objectives  of  the  U.S.  Army  MM  process  are  to~ 

•  Provide  a  single  integrated  process  to  manage  all  modifications 
to  U.S.  Army  materiel. 

•  Establish  better  management  of  modification  by  giving  the 
appropriate  program  manager  more  flexibility  and 
responsiveness. 

•  Enhance  block  modification  planning  and  execution  and  ensure 
that  production  and  retrofit  decisions  are  linked. 

•  Reduce  impact  on  field  caused  by  change. 

•  Provide  control  and  discipline  for  the  procedures  that  focus  on 
significant  modification  efforts  and  resulting  costs. 


Changes  to  system  configuration  are  normally  made  for  one  of  the 
following  reasons: 

•  Enhanced  safety. 

•  Enhanced  operational  capability. 

•  Energy  conservation. 

•  Operation  and  support  cost  reduction. 

•  Deficiency  correction. 
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Interoperability. 


Reasons  for  MM 

(con.) 


Comment 


Materiel  Developer 
Responsibilities 


•  Manpower  and  personnel  integration  (MANPRINT) 
considerations. 

A  modification  can  come  from  a  variety  of  sources:  contractor,  user,  or 
any  agency  in  the  U.S.  Army.  In  most  cases  the  originator  must  forward 
a  proposed  modification  to  the  proponent  for  consideration. 


Modification  should  be  considered  only  after  changes  to  doctrine  have 
been  evaluated  and  rejected  or  improvements  to  training  or  organization 
have  been  made.  Modification  to  existing  materiel  systems  is 
considered  prior  to  acquiring  or  developing  a  new  system.  When  a 
system  or  end  item  reaches  milestone  III,  it  is  scheduled  for  a  milestone 
decision  review  (MDR)  for  approval  to  begin  production.  The  proponent 
may  propose  modifications,  supported  by  adequate  documentation 
consistent  with  the  current  MM  guidance  Policy  for  TRADOC  Materiel 
Documentation  Review  and  Approval  and  AR  70-1,  Army  Acquisition 
Policy. 

MM  is  not  to  be  used  as  a  substitute  to  the  materiel  requirements 
documentation  process.  If  a  recommended  modification  will  alter  the 
capabilities  of  the  materiel  system  or  training  device,  then  a  change 
must  be  made  to  the  operational  requirements  document  (ORD)  or  a 
new  ORD  must  be  developed  and  approved.  Changes  to  materiel 
capabilities  are  to  be  based  on  approved  requirements. 


The  materiel  developer  (AMC)  serves  as  the  executive  agent  for  HQDA 
on  policy  matters  pertaining  to  the  MM  process  and  is  responsible  for 
coordinating  the  MM  process.  The  materiel  developer  will — 

•  Ensure  that  each  modification  is  adequately  reviewed  and 
evaluated,  all  integrated  logistics  support  items  are  properly 
examined,  and  MANPRINT  concerns  and  consideration  are 
addressed. 

•  Prepare,  staff  for  approval,  distribute,  and  maintain  the  test  and 
evaluation  master  plan  (TEMP),  when  required,  and  obtain 
critical  operational  issues  and  criteria  (COIC)  from  the  combat 
developer. 

•  Receive  and  decide  on  modifications  within  designated  authority. 
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Materiel  Developer 

Responelbilitiea 

(con.) 


Combat  Developer 
Responsibilities 


Ensure  that  upgrades  to  simulators  and  training  devices  caused 
by  a  system  change  (or  vice  versa)  are  included  in  the 
modification  actions. 

Review  the  combat  developer  coordination  check  sheet  to 
determine  if  formal  coordination  with  the  combat  developer  is 
required. 

Prepare  the  system  improvement  plan  (SIP)  for  review  by  the 
program  executive  officer  (PEO)  or  materiel  developer  and  the 
combat  developer. 


The  Combat  developer  is  the  primary  TRADOC  agency  responsible  for 
the  MM  process.  This  responsibility  includes  involving  the  training 
developer  and  the  materiel  developer  in  coordinating  modifications  that 
impact  their  respective  areas.  The  combat  developer  provides  a 
position  recommendation  to  the  designated  decision  level  on  the 
following  topics: 

•  Need. 

•  Funding  requirements. 

•  SIP  priority. 

•  SIP  impact. 

•  Operating  and  support  cost. 

•  Training  and  training  devices. 

•  Threat. 

•  TEMP. 

•  Logistics  impact. 

•  MANPRINT  considerations. 

•  Doctrine. 

The  decision  authority  for  modifications  is  linked  to  funding  levels  of  the 
proposal  change.  For  the  proponent  that  link  may  be  the  combat 
developer,  school  commandant,  or  HQ  TRADOC  Materiel  Evaluation 
Committee  (TMEC).  Decisions  made  at  one  level  may  be  appealed  to 
the  next  higher  level. 
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Training  Developer 
Responsibilities 


System 

Improvement  Plan 
(SIP) 


Preplanned  Product 
Improvement  (P3I) 


Pertinent 
Regulations  and 
Publications 


To  interact  in  the  MM  process,  the  training  developer  must  coordinate 
closely  with  the  combat  developer.  In  most  cases  the  training 
developer’s  responsibility  is  to  assess  the  training  impact  of  the 
proposed  modifications  (for  example,  additional  instruction  at  the 
institution  sustainment  training  impacts,  and  training  device  hardware 
changes).  The  training  developer  must  ensure  that  the  level  and  the 
impact  of  these  modifications  are  provided  to  the  combat  developer  for 
inclusion  in  MM  documentation. 


The  SIP  is  a  requirements-oriented  document  designed  to  provide  a 
comprehensive  plan  of  all  ongoing  and  planned  modifications  to  a 
system.  The  program  sponsor  prepares  the  SIP  for  the  materiel 
developer  and  the  combat  developer  counterpart.  It  is  reviewed 
annually  in  conjunction  with  the  planning,  programming,  budgeting,  and 
execution  system  (PPBES)  cycle.  Modifications  requiring  approval  by 
the  program  sponsor  or  higher  authority  must  be  consistent  with  the 
requirements  shown  in  the  SIP.  The  combat  developer  prioritizes  the 
modifications  in  the  SIP.  A  SIP  is  prepared  for  all  acquisition  category 
(ACAT)  II  systems  and  higher  programs. 


P3!  is  the  planned  evolutionary  improvement  of  a  developmental  system 
to  enhance  future  application  of  projected  technology.  It  is  an 
acquisition  strategy  that  minimizes  risk  and  consciously  integrates 
advanced  technology  through  planned  incremental  upgrades  to  the 
developmental  system.  Included  under  the  P3I  concept  are 
improvements  planned  for  existing  systems  that  go  beyond  the  current 
performance  envelope  to  achieve  a  needed  operational  capability.  P3I 
requirements  are  documented  in  the  system  or  nonsystem  training 
device  MNS  and  ORD,  and  the  funding  considerations  for  P3!  are 
included  in  the  total  life  cycle  cost  estimate  of  the  developmental 
program. 


AR  70-1 ,  Army  Acquisition  Policy 

HQ  TRADOC  Memorandum,  Subject:  Policy  for  TRADOC  Materiel 
Documentation  Review  and  Approval,  dated  21,  April  1993. 
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APPENDIX  A 


NONSYSTEM  TRAINING  DEVICE  LIFE  CYCLE  MODEL 


Appendix  A 

Nonsvstem  Training  Device  Life  Cycle  Model 


Introduction 


Purpose 


NSTD  LCM 


Training  devices  follow  the  same  life  cycle  process  as  weapon  or 
equipment  systems.  This  process  is  commonly  referred  to  as  the  life 
cycle  model  (LCM)  and  is  described  in  chapter  2  of  this  procedural 
guide.  The  LCMs  in  this  appendix  has  been  tailored  to  show  the 
relationships  and  interrelationships  of  the  training  developer’s  actions 
and  products  within  the  NSTD  acquisition  process. 


The  purpose  of  the  life  cycle  model  contained  in  this  appendix  is 
twofold: 

•  To  graphically  present  the  life  cycle  model  of  an  NSTD  from 
identification  of  the  training  deficiency  through  fielding  and 
postfieldlng  actions. 

•  To  provide  quick  reference  to  the  appropriate  section  of  the 
procedural  guide  covering  the  training  developer's  actions  and 
requirements  as  the  NSTD  proceeds  through  the  management 
model. 


Since  the  NSTD  has  its  own  requirements  document,  the  LCM  is  tied  to 
the  peculiarities  of  the  development  and  approval  of  the  NSTD 
operational  requirements  document  (ORD).  The  model  used  for  this 
purpose  is  based  on  the  NSTD  acquisition  process  outline  discussed  in 
chapter  2  of  this  procedural  guide.  Research,  development,  and 
acquisition  of  NSTDs  differ  somewhat  from  systems.  These  differences 
are  evident  in  the  decision  points  and  training  developer  actions 
depicted  in  the  LCM  shown  on  pages  A-3  and  A-4.  A  comparison  of 
this  model  with  the  system  model  shown  in  appendix  B  will  help  point 
out  these  differences.  The  NSTD  LCM  is  presented  in  two  formats. 
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Pertinent 
Regulations  and 
Publications 


Related  Pages 


•  The  model  on  page  A-3  presents  in  a  sequential  line  each  of  the 
requirements  for  the  process.  This  format  highlights  with 
diamonds  specific  decision  points  throughout  the  process.  The 
agency  responsible  for  the  action  is  shown.  Page  numbers  by 
each  action  refer  to  a  specific  location  in  the  procedural  guide 
where  information  pertinent  to  that  action  can  be  found.  This 
format  provides  all  of  the  major  actions  and  supporting 
documents  that  are  required  in  the  NSTD  acquisition  process. 

•  The  model  on  page  A-4  is  presented  in  less  detail  and  is 
designed  to  show  the  interrelationship  of  the  actions  taking  place 
throughout  the  materiel  acquisition  process. 

Key  features  of  this  model  are  the  following: 

•  All  major  actions  and  products  for  the  process  are  depicted 
relative  to  the  acquisition  milestones  and  phases. 

•  Decision  points  are  highlighted  and  shown  as  diamonds. 

•  Actions  and  products  are  keyed  to  the  pages  in  the  procedural 
guide  where  information  pertinent  to  related  procedures  can  be 
found. 
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Appendix  B 

System  and  Training  Subsystem  Life  Cycle  Model 


Introduction 


Purpose 


System  LCM 


Training  subsystems,  including  training  devices,  are  developed  and 
procured  within  the  same  acquisition  process  as  the  weapon  or 
equipment  system  that  they  will  support.  This  process  is  commonly 
referred  to  as  the  Life  Cycle  Model  (LCM)  and  is  described  in  chapter  2 
of  this  procedural  guide.  The  LCM  in  this  appendix  has  been  tailored  to 
show  the  relationships  and  interrelationships  of  the  training  developer’s 
actions  and  products  within  the  system  development  and  acquisition 
process. 


The  purpose  of  the  LCM  contained  in  this  appendix  is  twofold: 

•  To  graphically  present  the  life  cycle  of  a  system  and  its 
associated  training  subsystem  from  identification  of  the 
requirement  through  fielding  and  postfielding  actions. 

•  To  provide  quick  reference  to  the  appropriate  section  of  the 
procedural  guide  covering  the  training  developer’s  actions  and 
requirements  as  the  system  with  its  training  subsystem  proceeds 
through  the  model. 


Since  training  devices  and  other  training  support  equipment  are 
developed  concurrently  with  the  system  they  will  support,  it  is  necessary 
to  depict  the  training  developer’s  actions  within  the  framework  of  the 
system’s  LCM.  The  LCM  used  for  this  purpose  is  a  tailored  LCM  based 
on  the  system  TADSS  acquisition  process  outline  discussed  in  chapter  2 
of  this  procedural  guide.  The  model  in  this  appendix  has  been  further 
tailored  to  show  actions  and  products  required  from  combat  developers 
and  training  developers.  The  LCM  for  developing  systems  and  training 
subsystems  is  presented  in  two  formats. 
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•  The  model  on  page  B-3  presents  in  a  sequential  line  each  of  the 
requirements  for  the  process.  This  format  highlights  as 
diamonds  specific  decision  points  throughout  the  process.  The 
agency  responsible  for  the  action  is  shown.  Page  numbers  by 
each  action  refer  to  a  specific  location  in  the  procedural  guide 
where  information  pertinent  to  that  action  can  be  found.  This 
format  provides  all  of  the  major  actions  and  supporting 
documents  that  are  required  in  the  system  and  training 
subsystem  acquisition  process. 

•  The  model  on  page  B-4  is  presented  in  less  detail  and  is 
designed  to  show  the  interrelationship  of  concurrent  actions 
taking  place  throughout  the  materiel  acquisition  process. 

Key  features  of  this  model  are  the  following: 

•  All  major  actions  and  products  for  the  process  are  depicted 
relative  to  the  acquisition  milestones  and  phases. 

•  Decision  points  are  highlighted  and  shown  as  diamonds. 

•  Actions  and  products  are  keyed  to  the  pages  in  the  procedural 
guide  where  information  pertinent  to  related  procedures  can  be 
found. 
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Acronyms 


ACAT 

Acquisition  Category 

AC 

Active  Component 

ALDT 

Administrative  and  Logistics  Down  Time 

AMC 

Army  Materiel  Command 

AMSAA 

U.S.  Army  Materiel  Support  Analysis  Activity 

AMTAS 

Army  Modernization  Training  Automation  System 

AOIC 

Additional  Operational  Issues  and  Criteria 

ARSTAF 

Army  Staff 

ARTEP 

Army  Training  Evaluation  Plan 

ASARDA 

Assistant  Secretary  of  the  Army  for  Research,  Development  and  Acquisition 

ASI 

Additional  Skill  Identifier 

ATSC 

Army  Training  Support  Center 

BCE 

Baseline  Cost  Estimate 

BCS 

Baseline  Comparative  System 

BDP 

Battlefield  Development  Plan 

BOC 

Best  Operational  Capability 

BOI 

Basis  of  Issue 

BO  IP 

Basis  of  Issue  Plan 

BOIPFD 

BOIP  Feeder  Data 

BTA 

Best  Technical  Approach 

C3! 

Command,  Control,  Communications,  and  Intelligence 

CAC 

Combined  Arms  Command 
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CAC-T 


CASCOM 

CATS 

CFP 

CG 

CINC 

CNETP 

COEA 

COIC 

DA 

DAP 

DCSCD 

DCSOPS 

DCST 

DIA 

DMD 

DOD 

DODI 

DPAMMH 

DS 

DTLOMS 

ECA 

ECCM 

ECP 


Combined  Arms  Command-Training 
Combined  Armc  Support  Command 
Combined  Arms  Training  Strategy 
Concept  Formulation  Package 
Commanding  General 
Commanojr  in  Chief 

Consolidated  New  Equipment  Training  Plan 

Cost  and  Operational  Effectiveness  Analysis 

Critical  Operational  Issues  and  Criteria 

Department  of  the  Army 

Designated  Acquisition  Program 

Deputy  Chief  of  Staff  for  Combat  Development 

Deputy  Chief  of  Staff  for  Operations  and  Plans 

Deputy  Chief  of  Staff  for  Training 

Defense  Intelligence  Agency 

Device  Management  Directorate 

Department  of  Defense 

Department  of  Defense  Instructions 

Direct  Productive  Annual  Maintenance  Man-hours 

Direct  Support 

Doctrine,  Training,  Leader  Development,  Organizations,  Materiel  and  Soldier 
Early  Comparability  Analysis 
Electronic  Counter-Countermeasures 
Engineering  Change  Proposal 
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ERC 

EUT&E 

FD/SC 

FDT&E 

FOC 

FOT&E 

FSD 

GOWG 

GS 

HARDMAN 

HFE 

HQ 

HQDA 

ILS 

ILSP 

IOC 

IOT&E 

IPR 

IT 

JWG 

LCCS 

LCM 

LRAMP 

LRRDAP 


Executive  Review  Committee 

Early  User  Test  and  Experimentation 

Failure  Definition  and  Scoring  Criteria 

Force  Development  Test  and  Experimentation 

Full  Operational  Capability 

Follow-on  Operational  Test  and  Evaluation 

Full-scale  Development 

General  Office  Working  Group 

General  Support 

Hardware  Versus  Manpower 

Human  Factors  Engineering 

Headquarters 

Headquarters,  Department  of  the  Army 

Integrated  Logistics  Support 

Integrated  Logistics  Support  Plan 

Initial  Operating  Capability 

Initial  Operational  Test  and  Evaluation 

In-Process  Review 

Innovative  Test 

Joint  Working  Group 

Life  Cycle  Cost  Summary 

Life  Cycle  Model 

Long  Range  Army  Materiel  Requirements  Plan 

Long  Range  Research  Development  and  Acquisition  Plan 
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LSA 

Logistical  Support  Analysis 

LTA 

Local  Training  Area 

MACOM 

Major  Army  Command 

MANPRINT 

Manpower  and  Personnel  Integration 

MAV 

Minimum  Acceptable  Value 

MDEP 

Management  Decision  Package 

MDR 

Milestone  Decision  Review 

MJWG 

MANPRINT  Joint  Working  Group 

MM 

Modification  Management 

MNS 

Mission  Need  Statement 

MOS 

Military  Occupational  Specialty 

MP 

Mission  Profile 

MR 

Maintenance  Ratio 

MSC 

Major  Subordinate  Command 

MTBF 

Mean  Time  Between  Failure 

MTTR 

Mean  Time  To  Repair 

NATO 

National  Atlantic  Treaty  Organization 

NBC 

Nuclear,  Biological,  and  Chemical 

NBCC 

Nuclear,  Biological,  and  Chemical  Contamination 

NDI 

Nondevelopmental  Item 

NET 

New  Equipment  Training 

NETP 

New  Equipment  Training  Plan 

NGB 

National  Guard  Bureau 

NSTD 

Nonsystem  Training  Device 
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OCAR 

Office  of  the  Chief,  Army  Reserve 

OFT 

Operational  Feasibility  Test 

OIC 

Operational  Issues  and  Criteria 

OMS 

Operational  Mode  Summary 

ONS 

Operational  Need  Statement 

OPTEC 

Operational  Test  and  Evaluation  Command 

OPTEMPO 

Operating  Tempo 

ORD 

Operational  Requirements  Document 

P3! 

Preplanned  Product  Improvement 

PEO 

Program  Executive  Officer 

PFTEA 

Postfielding  Training  Effectiveness  Analysis 

PIP 

Product  Improvement  Program 

PM 

Project  Manager 

POC 

Point  of  Contact 

POM 

Program  Objective  Memorandum 

POI 

Program  of  Instruction 

PPBES 

Planning,  Programming,  Budgeting,  and  Execution  System 

PPBS 

Planning,  Programming,  and  Budgeting  System 

QQPRI 

Qualitative  and  Quantitative  Personnel  Requirements  Information 

RAM 

Reliability,  Availability,  and  Maintainability 

RC 

Reserve  Component 

R&O 

Research  and  Development 

RDA 

Research,  Development,  and  Acquisition 

ROTE 

Research,  Development,  Test,  and  Evaluation 
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RFP 

ROM 

RRC 

RRR 

RTS 

SAT 

SIP 

SMMP 

SOP 

SOW 

SSI 

STD 

STID 

STRAP 

STRICOM 

T&E 

TADSS 

TC 

TDA 

TDAD 

TDRRC 

TEA 

TEMP 

TIWQ 
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Request  for  Proposal 
Rough  Order  of  Magnitude 
Requirements  Review  Committee 
RAM  Rationale  Report 
Ranges,  Targets,  and  Simulators 
Systems  Approach  to  Training 
System  Improvement  Plan 
System  MANPRINT  Management  Plan 
Standing  Operating  Procedure 
Statement  of  Work 
Specialty  Skill  Identifier 
System  Training  Device 
Systems  Training  Integration  Division 
System  Training  Plan 

Simulation,  Training,  and  Instrumentation  Command 
Testing  and  Evaluation 

Training  Aids,  Devices,  Simulations,  and  Simulators 
Type  Classified 

Table  of  Distribution  and  Allowances 

Training  Development  and  Analysis  Directorate 

Training  Device  Requirements  Review  Committee 

Training  Effectiveness  Analysis 

Test  and  Evaluation  Master  Plan 

Test  Integration  Working  Group 
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TMA 

Training  Mission  Area 

TMDE 

Test,  Measurement,  and  Diagnostic  Equipment 

TOA 

Trade-Off  Analysis 

TOD 

Trade-Off  Determination 

TOE 

Table  of  Organization  and  Equipment 

TRADOC 

Training  and  Doctrine  Command 

TRASSO 

TRADOC  System  Staff  Officer 

TSC 

Training  Support  Center 

TSR 

Training  Support  Requirements 

TSWG 

Training  Support  Work  Group 

TT 

Technical  Testing 

TTSP 

Training  Test  Support  Package 

USAFISA 

U.S.  Army  Force  Integration  Support  Agency 

USAR 

U.S.  Army  Reserve 

WARM 

Wartime  Reserve  Modes 
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